我有一张有14亿logging的桌子。 表结构如下：
CREATE TABLE text_page ( text VARCHAR(255), page_id INT UNSIGNED ) ENGINE=MYISAM DEFAULT CHARSET=ascii 要求是为列text创build一个索引。
桌子大小约为34G。
我试图通过以下声明创build索引：
ALTER TABLE text_page ADD KEY ix_text (text)
经过10个小时的等待，我终于放弃了这个方法。
这个问题有没有可行的解决办法？
更新 ：表不太可能被更新或插入或删除。 在列text上创build索引的原因是因为这种sql查询会频繁执行：
SELECT page_id FROM text_page WHERE text = ?
更新 ：我通过分区表解决了这个问题。
该表格被分成40个栏目text 。 然后在桌子上创build索引需要大约1个小时才能完成。
当表格大小变得非常大时，似乎MySQL索引创build变得非常慢。 分区将表格缩小为更小的中继。
难道是你的系统只是没有达到任务？ 我不使用MySQL（这里是SQL Server），但我知道索引一个8亿条目表的痛苦。 基本上….你需要正确的硬件（如：许多快速光盘）。 我现在使用近十几个Velociraptors，performance很棒;）
SQL服务器（不是MS SQL Server，而是使用SQL的数据库服务器）随着光盘访问而生存，并且正常的光盘不能满足较大操作的要求。
您可能需要为文本字段的第一个（例如10个）字符创build索引。
从文档：
可以创build仅使用列值的前导部分的索引，使用col_name（length）语法指定索引前缀长度：
CREATE INDEX ix_text ON text_page (text(10))
把sort_buffer_size设置为4GB（或者你可以根据你有多less内存来设置）。
现在，创build索引正在做一个sorting，但由于你有一个32MB的sort_buffer_size，基本上是不必要地硬盘驱动器。
如果您不需要进行如下查询：
SELECT page_id FROM text_page WHERE text LIKE '?%';
我会build议创build一个新的哈希列，并按列索引表。 表+索引的整体大小可能要小得多。
UPD ：顺便说一下，14亿个主键整数约占6 GB，即string的平均长度小于30个字符，即对索引进行索引可能更为可取。
你还应该看看MERGE存储引擎。
我已经通过分区表解决了这个问题。
该表格被分成40个栏目text 。 然后在桌子上创build索引需要大约1个小时才能完成。
当表格大小变得非常大时，似乎MySQL索引创build变得非常慢。 分区将表格缩小为更小的中继。
一种方法是使用索引集创build一个新表，并将数据复制到新表中。
另外，确保你有足够的临时空间。
如果你仍然想知道如何做到这一点，我build议你使用在线改变表格工具。
网上有很多，其中着名的有：
我们对于大桌子（超过500mil的logging）也有同样的问题，而且这种改变也很完美。 它创build一个新的tmp表，在原始表上添加触发器（用于新的更新/删除/插入logging），同时它将所有logging复制到新表（使用新结构）
祝你好运！