我有一个MySQL数据库中的表,大约有25000条记录。每个记录有大约200个字段,其中许多是TEXT。关于结构我没有办法做到 - 这是从具有16年记录的旧平面文件数据库迁移而来的,许多字段都是“笔记”类型的自由文本条目。MySQL通过语句提高订单的速度
用户可以查看任意数量的字段,并按任何单个字段和任意数量的限定符进行排序。这种情况有很大的放缓,通常需要几秒钟,有时甚至需要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。
我认为现在是时候重建你的表和数据库结构,即使你说你不能这样做。您至少可以查看右列类型的所有列。 – 2012-03-06 11:12:41
@PeterKiss无处不在我能够使用更优化的数据类型,但是正如我所提到的,其中很多是“笔记”类型字段。任何超过我所做的事情都不会发生。没有问题,它运行良好 - 瓶颈就是这样。 – momo 2012-03-06 11:15:33
如果我是你,我会监视所有在后台查询(又名保存所有查询,如果可能的话)然后我会运行他们与解释关键字和收集最常用的列和建立他们的sima索引。列上的单个索引不会帮助! – 2012-03-06 11:19:47