调整 InnoDB 表,在每个表上创建一组适当的索引。有关详细信息,请参阅第 10.3.1 节“MySQL 如何使用索引”。请遵循以下 InnoDB 索引指南:To tune queries for InnoDB tables, create an
appropriate set of indexes on each table. See
Section 10.3.1, “How MySQL Uses Indexes” for details. Follow these
guidelines for InnoDB indexes:
由于每个
InnoDB表都有一个主键(无论您是否请求),因此请为每个表指定一组主键列,这些列将在最重要且时间关键的查询中使用。Because eachInnoDBtable has a primary key (whether you request one or not), specify a set of primary key columns for each table, columns that are used in the most important and time-critical queries.不要在主键中指定太多或太长的列,因为这些列值在每个二级索引中都会重复。当索引包含不必要的数据时,读取该数据的 I/O 以及缓存该数据的内存会降低服务器的性能和可扩展性。Do not specify too many or too long columns in the primary key, because these column values are duplicated in each secondary index. When an index contains unnecessary data, the I/O to read this data and memory to cache it reduce the performance and scalability of the server.
不要为每一列创建单独的二级索引,因为每个查询只能使用一个索引。很少测试的列或仅具有几个不同值的列上的索引可能对任何查询都没有帮助。如果您对同一个表有多个查询,并测试不同的列组合,请尝试创建少量的串联索引,而不是大量的单列索引。如果索引包含结果集所需的所有列(称为覆盖索引),则查询可能能够完全避免读取表数据。Do not create a separate secondary index for each column, because each query can only make use of one index. Indexes on rarely tested columns or columns with only a few different values might not be helpful for any queries. If you have many queries for the same table, testing different combinations of columns, try to create a small number of concatenated indexes rather than a large number of single-column indexes. If an index contains all the columns needed for the result set (known as a covering index), the query might be able to avoid reading the table data at all.
如果索引列不能包含任何
NULL值,请在创建表时将其声明为NOT NULL。当优化器知道每列是否包含NULL值时,它可以更好地确定哪个索引对查询最有效。If an indexed column cannot contain anyNULLvalues, declare it asNOT NULLwhen you create the table. The optimizer can better determine which index is most effective to use for a query, when it knows whether each column containsNULLvalues.您可以使用 第 10.5.3 节,“优化 InnoDB 只读事务” 中的技术来优化
InnoDB表的单查询事务。You can optimize single-query transactions forInnoDBtables, using the technique in Section 10.5.3, “Optimizing InnoDB Read-Only Transactions”.