In a code review, the source code is read by a human. This is often someone other than the original developer, but that's not a requirement. For example, the Personal Software Process enables personal code reviews guided by checklists of specific problems to identify. Alternatively, there are a number of techniques that involve other people - pair programming, over-the-shoulder checks, and formal inspections.
Regardless of the technique used, there are a number of reasons why a code review would be performed, although some techiques lend themselves better to specific purposes. For example, a large amount of code written by a new developer could be reviewed to ensure that they are following the team's conventions and are understanding the design and implementation goals of the team. Code reviews also allow for checking for logic errors and security problems. Tests can also be reviewed to ensure that the test cases correspond to requirements and that they are providing appropriate coverage.
Static analysis of code is performed by various tools scanning the source files, and in some cases, the binary files, to identify potential problems, ranging from indexing errors to unneeded assignments to security holes. These tools typically produce reports that indicate the location and severity of possible issues.
Often, static analysis and code reviews are used together to provide coverage. In my experiences, individual developers run static analysis over their own code prior to a code review. After reviewing the results of the static analysis, they correct any issues that might cause problems, then submit their code for review. By finding and correcting problems that are easily identified automatically, the human code reviewers can focus their efforts on a different subset of problems.