我有一个大表，表的大小是GB的130 GB左右。每天都会将数据转储到表格中。
我想优化表格......任何人都可以建议我应该怎么做？
任何输入都会有很大的帮助。
答案 0 :(得分：4)
这取决于您如何优化它。
对于查询速度，包括多列索引在内的适当索引将是一个非常好的起点。对您的所有查询进行解释，了解占用这么多时间的内容。优化读取数据的代码以存储它而不是重新查询。
如果旧数据不太重要或者您需要处理太多数据，则可以按年，月，周或日轮换表。这样，数据写入始终是一个非常小的表。旧表已经过时（即tablefoo_2011_04），因此您有积压。
如果您尝试在同一个表中优化大小，请确保使用适当的类型。如果获得可变长度字符串，请使用varchar而不是静态大小的数据。不要将字符串用于状态指示符，将enum或int与辅助查找表一起使用。
服务器应该有很多ram，因此它不会一直存在磁盘。
您还可以查看使用缓存层，例如memcached。
有关实际问题，您的情况以及您要优化的内容的更多信息会有所帮助。
答案 1 :(得分：2)
如果您的表是一种记录表，可以有几种优化策略。
（1）仅存储基本数据。
（2）将表格固定为格式。
（3）总结旧数据并定期将其转储到其他表中。
（4）不要为大表使用太多索引。
（5）使用ARCHIVE引擎。
答案 2 :(得分：0)
您应该向我们展示您的SHOW CREATE TABLE表名输出的内容，以便我们可以看到列，索引等。
从一切看来，似乎MySQL的partitioning是你需要实现的，以进一步提高性能。
答案 3 :(得分：0)
一些可能的策略。
如果数据集太大，则可能有用地冗余地存储某些信息：如果某些记录的访问频率高于其他记录，则保留缓存表，对信息进行非规范化（限制连接数或创建表少于列，所以你有一个精益表，以保持在内存中），或保持总结快速查找总数。
汇总表可以通过定期生成它们或通过使用触发器来保持同步，或者甚至通过在最近一天使用缓存表来组合两者来计算实际总数，以及摘要对于历史数据...将提供完全精确，而不需要读取完整索引。测试看看在您的情况下提供最佳性能的因素。
按期间拆分您的餐桌当然是一种选择。这就像分区一样，但是Mayflower Blog建议自己做，因为MySQL实现似乎有一定的局限性。
除此之外：如果这些历史表中的数据永远不会更改，并且您希望减少空间，则可以使用myisampack。支持索引（您必须重建）并报告性能增益，但我怀疑您将在读取单个行时获得速度，但在大型读取时面临性能下降（因为许多行需要解压缩）。
最后：你可以从历史数据中考虑你需要什么。它是否需要与最近的条目完全相同的信息，或者是否有不重要的东西？我可以想象，如果你有一个访问日志，例如，它存储各种信息，如ip，referal url，请求的URL，用户代理......也许在5年的时间内，用户代理根本不知道，将来自一个ip的一个页面+ css + javascript +图像的所有请求组合成一个条目（对于精确文件可能具有不同的多对一表格），并且referal URL仅需要出现次数并且可以与确切的时间或IP分离。
答案 4 :(得分：0)
不要忘记考虑存储数据的媒体的速度。我认为你可以使用raid磁盘来加速访问，或者可以将表存储在RAM中但130GB可能是一个挑战！然后考虑处理器。我意识到这不是你问题的直接答案，但它可能有助于实现你的目标。
答案 5 :(得分：0)
你仍然可以尝试使用表空间或@Evan建议的“table-per-period”结构进行分区。
如果您的全文搜索失败，可能应该去Sphinx / Lucene / Solr。外部搜索引擎绝对可以帮助您加快速度。
如果我们讨论的是表结构，那么应尽可能使用最小的数据类型。
如果optimize table太慢而且对于真正大的表是正确的，您可以备份此表并恢复它。当然，在这种情况下，您需要停机一段时间。
作为底线： 如果您的全文搜索问题比应用任何表更改之前的问题尝试使用外部搜索引擎。