批量删除后是否需要重新索引 mysql 表?

Aja*_*jay 11 mysql innodb performance delete performance-tuning

我在 MySQL 中有一个表,每秒钟都有很多 INSERT 和 SELECT。并且每天都会批量删除一些旧数据。删除后是否需要重新索引表?我想提高性能。有人可以提出一些建议吗?使用“innodb”作为存储引擎。我需要改变它吗?我认为它更适合并发插入和选择。请提出您的建议。我需要重新索引吗?

提前致谢..

小智 11

使用 InnoDB 时需要优化表吗?是和否,取决于您的工作负载以及您是否遇到性能问题。

来自MySQL 文档的无耻复制粘贴:

对于 InnoDB 表,OPTIMIZE TABLE 映射到 ALTER TABLE,它重建表以更新索引统计信息并释放聚集索引中未使用的空间。当您在 InnoDB 表上运行 OPTIMIZE TABLE 时,它会显示在输出中,如下所示:

mysql> OPTIMIZE TABLE foo;
+----------+----------+----------+-------------------------------------------------------------------+
| Table    | Op       | Msg_type | Msg_text                                                          |
+----------+----------+----------+-------------------------------------------------------------------+
| test.foo | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.foo | optimize | status   | OK                                                                |
+----------+----------+----------+-------------------------------------------------------------------+
Run Code Online (Sandbox Code Playgroud)

此操作不使用快速索引创建。二级索引的创建效率不高,因为键是按照它们在主键中出现的顺序插入的。请参见第 14.14.6 节,“快速索引创建的限制”。

InnoDB 使用页面分配方法存储数据,并且不会像传统存储引擎(例如 MyISAM)那样受到碎片化的影响。在考虑是否运行优化时,请考虑您的服务器将处理的事务工作量:

  • 预计会有一定程度的碎片化。InnoDB 只填充 93% 的页面,以便为更新留出空间而不必拆分页面。

  • 删除操作可能会留下空白,使页面填充量低于预期,这可能值得优化表。

  • 当有足够的空间可用时,对行的更新通常会重写同一页内的数据,具体取决于数据类型和行格式。请参阅第 14.10.5 节,“InnoDB 表的压缩如何工作”和第 14.12.1 节,“InnoDB 行存储概述”。

  • 随着时间的推移,高并发工作负载可能会在索引中留下空白,因为 InnoDB 通过其 MVCC 机制保留了相同数据的多个版本。请参阅第 14.5.12 节,“InnoDB 多版本控制”。


Rol*_*DBA 6

您可以重新索引表,甚至缩小表。但是,如果您想延迟这种基于磁盘的维护,您至少应该重新计算索引统计信息。

如果不重新计算索引统计信息,MySQL 查询优化器可能会为查询 EXPLAIN 计划做出错误的选择。如果不存在数据的统计信息仍然存在,这可能会对 SELECT 产生不利影响。MyISAM 和 InnoDB 都是如此。

您不必缩小表来计算索引统计信息,尽管它对整体性能会更好。

要计算表中所有索引的统计信息,您将运行

ANALYZE TABLE tablename;
Run Code Online (Sandbox Code Playgroud)

你可以每晚都这样做。它不会尝试对数据进行任何碎片整理或压缩。你可以通过运行每周一次OPTIMIZE TABLE tablename;。这也将ANALYZE TABLE tablename;在表的物理文件(.ibd对于 InnoDB 或.MYIMyISAM)或。