表是否结构合理？特别是，列是否具有正确的数据类型，每个表是否具有适合工作类型的适当列？例如，执行频繁更新的应用程序通常具有许多列较少的表，而分析大量数据的应用程序通常具有少量列较多的表。Are the tables structured properly? In particular, do the columns have the right data types, and does each table have the appropriate columns for the type of work? For example, applications that perform frequent updates often have many tables with few columns, while applications that analyze large amounts of data often have few tables with many columns.

是否有合适的索引来提高查询效率？Are the right indexes in place to make queries efficient?

您是否为每个表使用了适当的存储引擎，并充分利用所使用的每种存储引擎的优势和功能？特别是，选择一个事务性存储引擎，比如InnoDB，或者一个非事务性存储引擎，比如MyISAM，对于性能和可扩展性可能非常重要。Are you using the appropriate storage engine for each table, and taking advantage of the strengths and features of each storage engine you use? In particular, the choice of a transactional storage engine such as InnoDB or a nontransactional one such as MyISAM can be very important for performance and scalability.

每个表是否使用了适当的行格式？这个选择也取决于表使用的存储引擎。特别是，压缩表占用更少的磁盘空间，因此读写数据所需的磁盘 I/O 较少。压缩功能适用于各类 InnoDB 表的工作负载，以及只读的 MyISAM 表。Does each table use an appropriate row format? This choice also depends on the storage engine used for the table. In particular, compressed tables use less disk space and so require less disk I/O to read and write the data. Compression is available for all kinds of workloads with InnoDB tables, and for read-only MyISAM tables.

该应用程序是否使用了适当的锁策略？例如，在可能的情况下允许共享访问，以便数据库操作可以并发运行，以及在适当的时候请求独占访问，以便关键操作获得最高优先级。同样，存储引擎的选择也是很重要的。InnoDB存储引擎可以处理大多数锁问题，无需您的干预，从而提高数据库的并发性，并减少对代码进行实验和调优的需求。Does the application use an appropriate locking strategy? For example, by allowing shared access when possible so that database operations can run concurrently, and requesting exclusive access when appropriate so that critical operations get top priority. Again, the choice of storage engine is significant. The InnoDB storage engine handles most locking issues without involvement from you, allowing for better concurrency in the database and reducing the amount of experimentation and tuning for your code.

所有用于缓存的内存区域的大小都设置正确吗？也就是说，它们是否足够大以容纳经常访问的数据，但又不会大到导致物理内存过载和分页。需要配置的主要内存区域是InnoDB缓冲池和MyISAM键缓存。Are all memory areas used for caching sized correctly? That is, large enough to hold frequently accessed data, but not so large that they overload physical memory and cause paging. The main memory areas to configure are the InnoDB buffer pool and the MyISAM key cache.

磁盘寻道。磁盘找到一条数据需要时间。对于现代磁盘，这个平均时间通常低于 10 毫秒，因此理论上我们每秒可以进行大约 100 次寻道。随着新磁盘的出现，这个时间慢慢改善，并且很难针对单个表进行优化。优化寻道时间的方法是将数据分布到多个磁盘上。Disk seeks. It takes time for the disk to find a piece of data. With modern disks, the mean time for this is usually lower than 10ms, so we can in theory do about 100 seeks a second. This time improves slowly with new disks and is very hard to optimize for a single table. The way to optimize seek time is to distribute the data onto more than one disk.

磁盘读写。当磁盘到达正确位置时，我们需要读取或写入数据。对于现代磁盘，一块磁盘的吞吐量至少为 10–20MB/s。这比寻道更容易优化，因为你可以从多个磁盘并行读取。Disk reading and writing. When the disk is at the correct position, we need to read or write the data. With modern disks, one disk delivers at least 10–20MB/s throughput. This is easier to optimize than seeks because you can read in parallel from multiple disks.

CPU 周期。当数据在主内存中时，我们必须处理它以得到结果。相对于内存容量而言，大表是最常见的限制因素。但对于小表，速度通常不是问题。CPU cycles. When the data is in main memory, we must process it to get our result. Having large tables compared to the amount of memory is the most common limiting factor. But with small tables, speed is usually not the problem.

内存带宽。当 CPU 需要的数据超过 CPU 缓存能容纳的容量时，主内存带宽就会成为瓶颈。对于大多数系统来说，这是一个不常见的瓶颈，但需要注意。Memory bandwidth. When the CPU needs more data than can fit in the CPU cache, main memory bandwidth becomes a bottleneck. This is an uncommon bottleneck for most systems, but one to be aware of.