MySQL中的“CREATE INDEX”是线性操作吗？

Question

我的意思是：

如果在包含n行的表上创建索引需要t时间。在同一个表上创建索引1000*n需要大约1000*t时间。

我正在努力实现是估计它需要通过创建相同的索引创建的生产数据库的索引所需的时间远小于测试数据库。

Answer 1

索引创建本质上是一种排序操作，因此n log n平均而言它最多具有顺序的增长复杂性（您可能会发现它在某些情况下做得更好，并且不太可能做得更糟）。

如果您的所有相关数据页都适合 RAM 并且已经在 RAM 中，并且索引也适合，并且您的 DBMS 不会在创建完成之前强制写入索引页（因此索引块不会在磁盘上多次更新操作），那么将结果索引写入磁盘的速度将比执行排序所需的时间更重要 - 因此您可能会发现行数与创建索引所需的时间之间的线性关系更接近 -但如果你假设更糟的情况，你就不太可能感到不愉快了！

请记住，除非您不打算在操作期间停止对生产数据库的访问，否则任何索引创建都会与其他活动竞争 IO 带宽和/或锁，因此，如果您正在进行时间估计测试，您应该尝试考虑到这一点在另一个系统上，即使它的配置相同。

Answer 2

另外值得注意的是，如果您可以将索引的主轴与表的主轴分开，那么您将能够同时在两个磁盘上工作（仍然受限于中间磁盘控制器的速度，如果RAID 或类似的，但它仍然会比一个磁盘快）。

我意识到创建索引并不完全是一个模拟读写操作，但它确实大大加快了速度。

警告：我自己是一个 MSSQL 人，所以我不确定 MySQL，但我必须想象拆分主轴的概念并不是 SQLServer 和 Oracle 特有的（我在那里也听说过它，IIRC ）。我只是不知道如何去建立这个概念。但在 SQLServer 术语中，这意味着除此之外还有一个单独的文件组PRIMARY并将索引放在另一个文件组上，另一个文件组分配给一组不涉及的心轴PRIMARY（授予心轴放置与文件组完全是另一回事）