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

是否有适当的 索引来提高查询效率？

您是否为每个表使用了适当的存储引擎，并利用了您使用的每个存储引擎的优势和特性？特别是，选择事务存储引擎（例如 ） InnoDB 或非 事务存储引擎（例如 ）MyISAM 对于性能和可伸缩性非常重要。

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

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

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

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

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

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

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