fab*_*rik 15 mysql indexing performance logging
我正在尝试微调我的MySQL服务器,所以我检查我的设置,分析慢查询日志,并尽可能简化我的查询.
如果我正确编制索引,有时候就足够了.我读过某个地方(请纠正我,如果这是愚蠢的),多于我需要的索引会产生相同的效果,就像我没有任何索引一样.
有多少索引就足够了？你可以说它取决于数百个因素,但我很好奇我如何清理mysql-slow.log足够的以减少服务器负载.
此外,我看到了一些像这样"有趣"的日志条目:
# Query_time: 0 Lock_time: 0 Rows_sent: 22 Rows_examined: 44
SELECT * FROM `categories` ORDER BY `orderid` ASC;
有问题的表包含22行,索引设置为orderid.为什么这个查询毕竟出现在日志中？为什么检查44行,如果它只包含22行？
RC.*_*RC. 22
索引量和做太多的线将取决于很多因素.在像您的"类别"表这样的小表上,您通常不需要或不需要索引,这实际上会损害性能.原因是它需要I/O(即时间)来读取索引,然后需要更多I/O和时间来检索与匹配行关联的记录.当您仅查询索引中包含的列时的例外情况.
在您的示例中,您正在检索所有列并且只有22行,并且可以更快地执行表扫描并对其进行排序而不是使用索引.优化器可能/应该这样做并忽略索引.如果是这种情况,那么索引就是占用空间而没有任何好处.如果经常访问"类别"表,您可能需要考虑将其固定到内存中,以便db服务器可以访问它而无需始终转到磁盘.
添加索引时,需要平衡磁盘空间,查询性能以及更新和插入表中的性能.对于每天有数百万次更新的表,您可以在静态表上获得更多索引,并且不会发生太大变化.您将在那时开始感受索引维护的影响.您的环境中可接受的是,您只能由您和您的组织决定.
进行分析时,请务必生成/更新表和索引统计信息,以确保准确计算.
Pow*_*ord 13
作为一般规则,您应该在所有主键(您没有选择),所有外键以及通常用于获取行的任何其他字段上具有索引.
例如,如果我通常按用户名查找用户,即使用户ID是主键,我也会将其编入索引.
有多少索引完全取决于您运行的查询,正在进行的连接类型(如果有),表中存储的数据类型以及表的大小(以及许多其他因素).真的没有确切的科学.解释了解决如何优化查询的最佳工具.使用说明,您可以找出正在使用哪种连接,可以使用哪些键以及使用了哪个键(如果有)以及为连接中的每个表检查了多少行.
使用此信息,您可以决定如何键入表格和/或修改查询以提高查询效率.解释的语法非常简单.
EXPLAIN SELECT * FROM `categories` ORDER BY `orderid` ASC;
注意,解释不实际运行查询.因此,如果您使用它来调试运行5分钟的查询,则解释仍然非常快.
在添加索引时需要小心,因为它们会导致插入和更新变慢,而在非常大的表上,这种性能损失会变得明显.特别是如果相同的表用于大量读取.虽然添加大量索引通常不会破坏查询的性能,但您仍应将它们添加为yo
还要记住,MySQL 每个select语句最多使用一个索引(尽管如果使用连接,它也可以为每个连接使用一个).因此索引仅仅是因为浪费磁盘空间并且会降低数据库的写入速度.如果您通常在两列上使用where语句,那么执行一个包含这两列的索引,它将明显快于仅仅索引一列.
| 归档时间： |
|
| 查看次数： |
10279 次 |
| 最近记录： |