我在MySQL数据库中有一个包含大约25000条记录的表。每条记录有大约200个字段,其中许多是TEXT。关于结构,我无能为力 - 这是从旧的平面文件数据库迁移,它具有16年的记录,许多字段是“注释”类型的自由文本条目。
用户可以查看任意数量的字段,并按任意单个字段和任意数量的限定符进行排序。排序大幅放缓,通常需要几秒钟,有时甚至需要7-10秒。
示例语句可能如下所示:
select a, b, c from table where b=1 and c=2 or a=0 order by a desc limit 25
从来没有一个明星选择,并且总是有一个限制,所以我不认为该声明本身可以真正优化得多。
我知道索引可以帮助提高速度,但由于无法知道哪些字段将被排序,我必须索引所有200列 - 我读到的关于此的内容并非如此似乎是一致的。我知道在插入或更新记录时会有一个减速,但假设这是可以接受的,是否建议为每个列添加一个索引?
我已经读过sort_buffer_size,但似乎我读到的所有东西都与我读到的最后一件事冲突 - 是否建议增加这个值,或任何其他类似的值(read_buffer_size等)?
此外,主要标识符是他们在九十年代提出的疯狂模式。这是PK,所以应该通过PK(右?)来索引。记录已经(并且已经)提交给州和他们的客户,我无法更改格式。此列需要根据适当的逻辑进行排序,该逻辑涉及具有字符串连接和子字符串匹配的存储过程。这种特殊的排序特别慢,并且似乎没有缓存,即使这个字段被索引,所以我想知道是否有任何我可以做的事情来加速这个特定字段的排序(是默认订单。)
TYIA。
答案 0 :(得分:0)
我必须索引所有200列
这不是一个好主意。由于MySQL使用索引的方式,大多数索引可能永远不会被使用,同时仍会产生相当大的开销。 (有关详细信息,请参阅下面链接中的第7.3章)。但是,您可以尝试确定哪些列最常出现在WHERE
子句中,并对其进行索引。
从长远来看,你可能需要找到一种方法,将你的数据结构重新编写成更易于管理的东西,因为就像现在一样,它有“电子表格变成数据库”的味道,这不是一个好的气味
我读过sort_buffer_size,但它似乎就是我读过的所有内容 与我读到的最后一件事发生冲突 - 建议增加 此值或任何其他类似值(read_buffer_size, 等)?
总的来说,他回答是肯定的。但实际细节取决于您的硬件,操作系统和您使用的存储引擎。见第7.11章(尤其是下面链接中的7.11.4)
此外,主要标识符是他们提出的疯狂模式 九十年代。[...]我想知道我能做些什么来加快速度 此特定字段的排序(默认顺序)。
也许您可以在表中添加primarySortOrder
列,您可以在其中存储将映射PK顺序的数值(从您正在使用的存储过程预先缓存)。
Ant您一直在等待的链接:Chapter 7 from MySQL manual: Optimization
答案 1 :(得分:0)
为具有大量不同值的所有列添加索引,例如100或甚至1000或更多。随你调整这个数字。