And*_*dri 6 mysql partitioning
我有一个包含 150 万行、39 列的表，包含大约 2 年的销售数据，并且每天都在增长。在我们将其移动到新服务器之前我没有遇到任何问题，我们现在的内存可能更少。
目前查询需要很长时间。有人建议对导致大多数性能问题的大表进行分区，但我有几个问题。
分区执行时间是否较长？我担心由于性能缓慢，中途会发生一些事情，我会丢失数据。
我应该把它分成几年还是几个月？（我们通常会查看一个月内的数字，但有时我们会花几周或几年的时间）。我还应该对列进行分区吗？（我们有一些很少或从不使用的列，但我们稍后可能想使用它们）
（我同意比尔的回答；我将以不同的方式处理这个问题。）
什么时候需要对我的桌子进行分区？
可能永远不会。
它有可能提高其性能吗？
它更有可能稍微降低性能。
我有一个包含 150 万行的表
不够大，无法进行分区。
目前查询需要很长时间
通常这是由于缺乏一个好的索引，可能是一个“综合”索引。 其次是查询的表述。请向我们展示一个慢速查询以及SHOW CREATE TABLE.
大约2年的数据，并且每天都在增长
您最终会清除“旧”数据吗？如果是这样，这PARTITION BY RANGE(TO_DAYS(..))是一个很好的主意。然而，它只在清除期间有帮助。这是因为比快DROP PARTITION很多。DELETE...
我们现在的内存可能更少了。
如果您主要查看“最近”数据，那么内存大小 (cf innodb_buffer_pool_size)可能并不重要。这是由于缓存造成的。然而，听起来您正在进行表扫描，也许是不必要的。
我是否必须更改当前的 INSERT 或 SELECT
不需要。但是您可能PRIMARY KEY需要更改辅助键中的列。
分区执行时间是否较长？
慢 - 是的，因为它会复制整个表。注意：这意味着额外的磁盘空间，并且分区表将占用更多的磁盘。
中途会发生一些事情，我会丢失数据。
不用担心。新表已创建，然后非常快速地RENAME TABLE将其交换到位。
我应该把它分成几年还是几个月？
经验法则：目标是大约 50 个分区。对于“2 年及成长”，可能的选择是“每月”。
我们通常会查看一个月内的数字，但有时我们会花费数周或数年的时间
听起来像典型的“数据仓库”数据集？构建并逐步扩充包含每日统计数据的“汇总表”。通过该表，您可以快速获取每周/每月/每年的统计数据——速度可能快 10 倍。对于任何日期范围也是如此。这也对“内存不足”有很大帮助。
我还应该对列进行分区吗？（我们有一些很少或从不使用的列，但我们稍后可能想使用它们）
你不应该“永远”使用SELECT *; 相反，指定您实际需要的列。“垂直分区”是您建议的术语。有时它很实用。但我们需要看到SHOW CREATE TABLE 现实的列名称才能进一步讨论。
有关分区的更多信息：http://mysql.rjweb.org/doc.php/partitionmaint
有关汇总表的更多信息： http: //mysql.rjweb.org/doc.php/summarytables
在大多数情况下，最好使用索引而不是分区作为查询优化的主要方法。
关于 MySQL 中的分区，您应该了解的第一件事是这条规则：
分区表的分区表达式中使用的所有列都必须是该表可能具有的每个唯一键的一部分。
请在此处阅读有关此规则的更多信息：分区键、主键和唯一键。
此规则使许多表不符合分区条件，因为您可能希望按不属于该表中主键或唯一键的列进行分区。
第二件事要知道的是，分区仅有助于使用明确让优化器推断哪些分区保存您感兴趣的数据的条件的查询。这称为分区修剪。如果您运行的查询可以在任何或所有分区中查找数据，MySQL 必须搜索所有分区，并且与常规的非分区表相比，您不会获得任何性能优势。
例如，如果您按日期分区，但随后运行与特定用户帐户相关的数据查询，则必须搜索所有分区。
事实上，在这样的查询中使用分区表甚至可能会慢一点，因为 MySQL 必须连续搜索每个分区。
您询问对表进行分区需要多长时间。转换为分区表需要ALTER TABLE重组数据，因此与将数据复制到新表空间的任何其他更改大约需要相同的时间。这与表的大小成正比，但根据服务器的性能而变化很大。您只需对其进行测试，我们无法估计它在您的服务器上需要多长时间。