表结构是否正确？特别是，列是否具有正确的数据类型，每个表是否具有适合工作类型的列？例如，频繁更新的应用程序通常具有多个表和少量列，而分析大量数据的应用程序通常具有少量表和多个列。

是否正确地设置了索引以使查询高效？

是否使用了适合每个表的存储引擎，并充分利用了每个存储引擎的优势和功能？特别是，选择事务存储引擎，如InnoDB，或非事务存储引擎，如MyISAM，对性能和可扩展性非常重要。

每个表是否使用了适合的行格式？这也取决于表使用的存储引擎。特别是，压缩表使用较少的磁盘空间，因此需要较少的磁盘I/O来读取和写入数据。压缩功能适用于所有工作负载的InnoDB表，以及只读MyISAM表。

应用程序是否使用了适合的锁定策略？例如，允许共享访问以便数据库操作可以并发运行，并请求独占访问以便关键操作获得最高优先级。再次，存储引擎的选择非常重要。InnoDB存储引擎处理大多数锁定问题，而不需要您参与，从而提高了数据库的并发性，并减少了代码的试验和调整。

所有缓存内存区域是否正确地配置了大小？即，足够大以容纳频繁访问的数据，但又不至于过载物理内存并导致分页。主要的内存区域需要配置的是InnoDB缓冲池和MyISAM键缓存。

磁盘寻道。磁盘需要时间来找到一 piece of 数据。使用现代磁盘，平均时间通常低于10ms，因此我们可以理论上每秒执行大约100次寻道。这个时间随着新磁盘的出现而慢慢改善，并且很难为单个表进行优化。优化寻道时间的方法是将数据分布到多个磁盘上。

磁盘读取和写入。当磁盘处于正确位置时，我们需要读取或写入数据。使用现代磁盘，每个磁盘至少可以提供10-20MB/s的吞吐量。这比寻道时间更容易优化，因为您可以从多个磁盘并行读取。

CPU 周期。当数据在主内存中时，我们必须处理它以获得结果。与内存量相比，大的表格是最常见的限制因素。但是对于小表格，速度通常不是问题。

内存带宽。当 CPU 需要更多数据时，无法容纳在 CPU 缓存中，主内存带宽就会成为瓶颈。这是大多数系统中不常见的瓶颈，但需要注意。