MySQL表的分区似乎并没有提高性能

我有一个巨大的表，其中每个公司都有一个公司IDX唯一ID作为分区键

我有大约10000家公司，每家公司可能有多达200000行。 我增加了分区的数量，但我的查询性能似乎没有增加

我应该增加分区的数量吗？？对于有很多行的公司，每个公司最多有一个分区

对我来说，什么是最好的架构解决方案？

---

我听说过索引，但不确定它是否与我的情况相关。

如果所有SELECT、UPDATE和DELETE语句都在WHERE子句中包含分区列分区表达式，或者在join的ON子句中包含等效谓词，则分区将有助于提高性能和并发性。否则，如果我们的查询查看的是所有分区，那么我们将看不到性能改进

为了获得性能优势，我们需要优化器在执行计划中有效地使用分区修剪；消除所有已知找不到匹配行的分区

在开始创建更多分区之前，我们需要确保查询（至少是我们希望从中获得性能的查询）得到的执行计划正在得到分区修剪

我们应该首先检查执行计划，看看分区有什么影响。我们使用解释。较新版本的MySQL默认显示分区信息。对于较旧版本的MySQL，我们使用EXPLAIN分区来获取这些信息

问题中没有说明使用哪种类型的分区范围、列表、哈希、列、键、分区表达式是什么，或者WHERE子句是什么样子。所以我们不能冒险猜测是否需要分区修剪

索引

对于大型集合，索引总是相关的

我们需要创建和维护哪些索引，哪些索引最合适，实际上取决于正在执行的查询的实际组合

---

分区不能替代合适的索引

分区并不是让事情变得更快的神奇功能。在某些方面，它们实际上只不过是一个聚集索引，其中群集存储在单独的文件中，并且实际上可能会损害与分区条件无关的查询的性能。分区通常不是提高性能的第一件事，索引是。也许我可以对分区表进行索引？如果每个公司只能访问自己的行，跨公司进行的查询很少，那么分区是有意义的，但在这种情况下可以完全分离数据库；但即便如此，分区也不能替代适当的索引。例如，不管分区如何，如果您有很多基于日期的查询，那么用于日期条件的字段应该被索引。如果您有很多关于公司id和某个时间戳之类的查询，那么最好的索引通常是公司id、某个时间戳。。。。每个字段上没有两个单独的索引。请提供带分区或不带分区的SHOW CREATE TABLE，以便我们了解数据。并提供最重要的查询，因此我们可以帮助您建立索引和/或分区。我还为每个公司提供了时间戳，大多数情况下，我会请求一个特定的时间框架。在这种情况下我应该怎么做？使用EXPLAIN查看执行计划，并验证是否正在进行分区修剪。从问题中的描述来看，我们可能期望查询访问单个分区。我们应该核实这是怎么回事。为了访问特定的时间范围，我会确保我们在裸列上有可搜索的谓词比较，而不是在函数或其他表达式中包装的列，并定义了合适的索引；我们可能需要一个综合指数。只有一般性的问题陈述，我们只能给出一般性的指导方针，我们不能给出具体的建议。这一点我再强调也不为过。：使用EXPLAIN查看执行计划。