The short answer
The steps in decoding and executing the instruction are executed in parallel with the next step of the previous instruction. This technique is known as pipelining. See On RISC Processors below.
A single-issue RISC architecture will typically average slightly less than one instruction per cycle due to wait states and time taken for load/store operations that hit memory rather than just being register to register. Delay slots give you an architectural hook that may allow you to get some of this time back. See On RISC processors below.
An instruction cycle is the length of time needed to execute an instruction. This will vary with architecture and (in some cases) instructions. For example, most instructions on something like a MIPS R2000/3000 take one cycle. Instructions involving memory access (load/store, branch) take more than one cycle, although the delay slots mean you may be able execute something else (possibly just a NOP) in the delay slot. Non-pipelined architectures can have instruction cycles of several clock cycles, often varying with the addressing mode. See On RISC processors, Traditional CISC architecures and Hardwired Architectures below.
Multiple-issue designs can blur this concept somewhat by executing more than one instruction in parallel.
CISC processors can have instructions that take varying lengths of time. The exact number of clock cycles depends on the architecture and instructions. The varying number of clock cycles taken on CISC ISAs is one of the reasons they are hard to build into heavily pipelined architectures. See Traditional CISC architectures below.
The longer answer
For a single issue MIPS, SPARC or other CPU, all (for a first approximation) instructions issue in one cycle, although they can have something known as a 'delay slot.'
On RISC Processors
In this context, a single issue CPU is one where the CPU doesn't do any on-the-fly dependency analysis and parallel issuance of instructions in the way that modern CPUs do, i.e. they have just one execution unit that executes the instructions in the order they are read from memoty. More on this later.
Most older RISC processors are single-issue designs, and these types are still widely used in embedded systems. A 32-bit single-issue integer RISC core can be implemented in around 25,000-30,000 gates, so CPU cores of this type have very low power consumption and very small footprints. This makes them easy and cheap to integrate into SOC (system-on-chip) products.
RISC CPU designs are pipelined - processing the instruction is done in several stages, with each instruction being passed down the pipeline to the next stage every clock cycle. In most cases a single-issue pipelined CPU will execute something close to one instruction per clock cycle.
Some architectures have instructions like branching or load/store from memory where the additional cycle taken by the memory access is visible to the code.
For example, in a SPARC V7/V8 design the next instruction after a branch is actually executed before the branch itself takes place. Typically you would put a NOP into the slot after the branch but you could put another instruction into it if you could find something useful to do.
The MIPS R2000/R3000 architecture had a similar delay slot in the load/store instructions. If you loaded a value from memory, it would not actually appear in the register for another cycle. You could put a NOP in the slot or do something else if you could find something useful to do that was not dependent on the load operation you just issued.
If the memory was slower than the CPU, which was often the case, you might get additional wait states on memory accesses. Wait states freeze the CPU for one or more clock cycles until the memory access is completed. In practice, these wait states and extra time for memory accesses mean that single-issue CPU designs average slightly less than one instruction per clock cycle. Delay slots give you some possible opportunities to optimise code by executing some other instruction while a memory operation takes place.
Traditional CISC processors
CISC processors were designs that could have instructions taking varying lengths of time. Often they had more complex instructions implemented directly in hardware that would have to be done in software on a RISC CPU.
Most mainframe architectures and pretty much all PC designs up to the M68K and intel 386 were traditional microcoded CISC CPUs. These designs proved to be slower per-clock and used more gates than RISC CPUs.
An example of a microcoded architecture (MOS 6502) can be seen in emulation here. The microcode can be seen at the top of the image.
Microcode controls data flows and actions activated within the CPU in order to execute instructions. By looping through the steps in the microcode you can activate the parts of a CPU, moving data through ALUs or carrying out other steps. Re-usable components in the CPU can be co-ordinated over multiple clock cycles to execute an instruction. In the case of the 6502 some pipelined actions could also be executed by the microcode.
Microcoded designs used less silicon than hard-wired chips at the expense of potentially taking several clock cycles to complete an instruction. Depending on the design, these CPUs would take varying lengths of time per instruction.
Hardwired designs (not necessarily mutually exclusive with microcode) execute an instruction synchronously, or may have their own coordinators to do something across multiple clock cycles. They are typically faster at the expense of more dedicated hardware and are thus more expensive to implement than a microcoded design of equivalent functionality.
A famous example of this was the original Amdahl 470/6 CPU, which was a drop-in replacement for the CPU on certain IBM System/370 models. The Amdahl CPU was a hardwired design at a time when IBM's 370 CPUs were heavily based on microcode. The Amdahl CPU was about 3 times faster than the IBM CPUs they replaced.
Needless to say, IBM was not amused and this resulted in a court battle that ended up forcing IBM to open their mainframe architecture until the consent decree expired a few years ago.
Typically, a hardwired design of this type was still not as fast clock-for-clock as a RISC CPU as the varying instruction timings and formats didn't allow as much scope for pipelining as a RISC design does.
Most modern CPUs are multiple issue architectures that can process more than one instruction at a time within a single thread. The chip can do a dynamic dependency analysis on the incoming instruction stream and issue instructions in parallel where there is no dependency on the result of a previous computation.
The throughput of these chips depends on how much parallelism can be achieved in the code but most modern CPUs will average several instructions per cycle on most code.
Modern Intel and other x86/X64 ISA CPUs have a layer that interprets the old-school CISC instruction set into micro instructions that can be fed through a pipelined RISC-style multiple issue core. This adds some overhead that is not present on CPUs with ISAs that are designed for pipelining (i.e. RISC architectures such as ARM or PowerPC).
VLIW designs, of which the Intel Itanium is perhaps the best known, never took off as mainstream architectures, but IIRC there are a number of DSP architectures that use this type of design. A VLIW design makes multiple-issue explicit with an instruction word containing more than one instruction that is issued in parallel.
These were dependent on good optimising compilers, which identified dependencies and opportunities for parallelism, dropping instructions into the multiple slots available on each instruction word.
VLIW architectures work quite well for numerical applications as matrix/array ops tend to offer opportunities for extensive parallelism. The Itanium had a niche market in supercomputing applications for a while, and there was at least one supercomputer architecture - the Multiflow TRACE - was produced using an ISA of this type.
Memory and caching
Modern CPUs are much, much faster than memory, so direct reads from memory can generate hundreds of wait states which block the CPU until the memory access completes. Caching, now done in multiple layers, holds the most recently used memory locations in the cache. As CPUs typically spend the vast majority of time executing code in loops this means you get good hit rates of re-using memory locations that you've used recently. This property is called 'locality of reference.'
Where you get locality of reference the CPU can operate at close to optimum speed. Cache misses down to the next level incur a number of wait states; cache misses down to main memory can incur hundreds.
Thus, the actual throughput of CPU chips can be heavily dependent on the efficiency of memory access patterns. Whole books have been written on optimising code for this, and it's a complex topic in its own right.