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

是否已设置正确的 索引 以提高查询效率？

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

每个表是否使用了合适的行格式？此选择还取决于用于表的存储引擎。特别是，压缩表使用更少的磁盘空间，因此读取和写入数据所需的磁盘 I/O 更少。使用 InnoDB 表可以对所有类型的工作负载进行压缩，而对于只读 MyISAM 表也可以进行压缩。

应用程序是否使用了合适的 锁定策略？例如，尽可能允许共享访问，以便数据库操作可以并发运行，并在适当的时候请求独占访问，以便关键操作获得最高优先级。同样，存储引擎的选择也很重要。InnoDB 存储引擎可以处理大多数锁定问题，而无需您的参与，从而允许数据库中更好的并发性，并减少代码的实验和调整量。

所有用于 缓存的内存区域 的大小是否正确？也就是说，它们是否足够大以容纳频繁访问的数据，但又不会大到使物理内存过载并导致分页。要配置的主要内存区域是 InnoDB 缓冲池和 MyISAM 键缓存。

磁盘寻道。磁盘查找一段数据需要时间。对于现代磁盘，这方面的平均时间通常低于 10 毫秒，因此理论上我们每秒可以进行大约 100 次寻道。随着新磁盘的出现，这段时间会缓慢缩短，并且很难针对单个表进行优化。优化寻道时间的方法是将数据分布到多个磁盘上。

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

CPU 周期。当数据位于主内存中时，我们必须对其进行处理才能获得结果。与内存量相比，拥有大表是最常见的限制因素。但对于小表来说，速度通常不是问题。

内存带宽。当 CPU 需要的数据超过 CPU 缓存的容量时，主内存带宽就会成为瓶颈。对于大多数系统来说，这不是一个常见的瓶颈，但需要注意。