MYSQL优化137000行的表答案

【问题标题】：MYSQL Optimizing a table with 137000 rowsMYSQL优化137000行的表
【发布时间】：2009-06-05 11:21:49
【问题描述】：

我正在尝试优化redmine 数据库，以免它变得太痛苦；更改（基本上是所有 SVN 更改的日志）为 137000 行（ish），并且该表设置为基本默认设置。没有钥匙包装等。

表格如下

ID int[11] Auto Inc (PK)
changeset_id int[11]
action varchar[1]
path varchar[255]
from_path varchar[255]
from_revision varchar[255]
revision varchar[255]
branch  varchar[255]

索引：主要 (ID)，
changeset_id 设置为 INDEX BTREE

所有基于来自http://forge.mysql.com/wiki/Top10SQLPerformanceTips的信息的latin1字符集

表引擎是 InnoDB Pack Keys 设置为 Default（仅包 char varchar）

所有其他选项均已关闭。

优化它的最佳方法是什么？（条截断；o））

【问题讨论】：

你想优化什么？查询速度？占用磁盘空间？是时候进行全表扫描了？ ...
@S.Gehrig 对于这个巨大的表，我认为查询速度可能是最重要的一点。

标签： mysql redmine mysql-management

【解决方案1】：

有一些针对 mysql 的通用优化技术：首先是确保您的数据类型符合 ABC（参见 here）。然后从上到下遍历，ID 和 changeset_id 看起来不错，操作可能应该是 char1 而不是 varchar（如果可以将其留空，则可以为空（并且通常，请确保您的可空值在其他字段上设置正确）））。至于其他 5 个字段（取决于大小可能会在表格中占主导地位），字符串是正确的数据类型吗？（我猜是路径，from_path，分支，但也许修订应该是一个数字（我猜它不是，所以它支持 git 或其他东西））

此外，它们看起来像规范化目标，特别是因为“路径”和“修订”表可以规范化其中的四个（here's a basic tutorial，如果您需要的话）

【讨论】：

revision 需要是一个字符串以支持 git 和其他非数字 SCM。调整action 的大小可能是对的，我只看到“A”、“M”、“D”和“R”。

【解决方案2】：

这完全取决于您的读写特征，即您进行的查询，以及您对其进行写入的频率。

优化写入的方法是尽量减少索引的数量。理想情况下，您使用 MS SQL 服务器中的“聚集索引”和单调递增的键，确保将新记录写入表的末尾，并且不写入其他单独的索引。更好的是，如果您不需要任何事务功能，甚至可以跳过 DBMS 并写入某种普通的旧日志文件。

对于查询，可以随心所欲地复杂化。但是请记住，如果您需要从表中获取大量数据进行查询（即，不仅仅是根据键查找单个记录），表扫描可能不是一件坏事。通常，如果您要检查超过 3-5% 的表内容，则表扫描会非常快。同样，为此，一个普通的旧文件可能比 DBMS 更快。

如果您必须针对两者进行优化，请考虑针对写入进行优化，然后定期制作副本以针对查询进行优化，并针对副本执行查询。

【讨论】：