表是否结构良好？特别是，列是否有正确的数据类型，每个表是否有适当的列来支持特定工作？例如，频繁更新操作的应用程序通常有许多表和少数列，而分析大量数据的应用程序则有少数表和多数列。

是否使用了合适的索引以提高查询效率？

您是否为每个表选择了正确的存储引擎，并利用了每种存储引擎的优势和特性？特别是，选择事务性存储引擎，如InnoDB或非事务性存储引擎，如MyISAM对于性能和可扩展性至关重要。

每个表是否使用了合适的行格式？这个选择还取决于用于表的存储引擎。在所有工作负载中，InnoDB表都支持压缩，而只读MyISAM表也支持。

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

所有内存区域用于缓存是否大小正确？也就是说，足够大以容纳频繁访问的数据，但不至于过大，以至于超出物理内存并导致页面。主要的内存区域是InnoDB缓冲池和MyISAM键缓存。

磁盘寻道。磁盘找到数据所需的时间较长。随着现代磁盘而言，这个时间通常低于10ms，所以我们理论上可以做大约100次寻道操作每秒。这一时间随着新磁盘的出现而逐渐改善，但对于单个表来说很难优化。优化寻道时间的方式是将数据分布到多个磁盘上。

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

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

内存带宽。当CPU需要更多数据而不能全部放入CPU缓存时，主内存带宽就成为瓶颈。这对于大多数系统来说是一个不常见的瓶颈，但值得注意。