我相信我遇到了数据库缩放问题。 我现在有一个有近一百万行的表，当我们尝试创build一个新的实例时，我们的rails应用程序似乎挂起来了。 我注意到这也发生在我们销毁logging的时候。 但是，查找和更新非常快。
以下是表格中的一些信息：
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | | instances | InnoDB | 10 | Compact | 972380 | 1897 | 1845493760 | 0 | 152846336 | 0 | 922976 | 2009-03-04 18:34:07 | NULL | NULL | latin1_swedish_ci | NULL | | InnoDB free: 5120 kB | 并且：
+-------------------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | card_id | int(11) | YES | MUL | NULL | | | email_id | int(11) | YES | MUL | NULL | | | name | varchar(255) | YES | | NULL | | | subject | varchar(255) | YES | | NULL | | | prototype | text | YES | | NULL | | | forwards_count | int(11) | YES | | 0 | | | recipients_count | int(11) | YES | | 0 | | | sent_at | datetime | YES | MUL | NULL | | | created_at | datetime | YES | | NULL | | | body | text | YES | | NULL | | | updated_at | datetime | YES | | NULL | | | original_id | int(11) | YES | | NULL | | | saved | tinyint(1) | YES | | 1 | | | notify_on_receipt | tinyint(1) | YES | | 0 | | | total_views | int(11) | YES | | 0 | | | total_sends | int(11) | YES | | 0 | | | public | tinyint(1) | YES | MUL | 0 | | | approved | tinyint(1) | YES | MUL | 0 | | | sender_copy | int(11) | YES | | NULL | | | recipient_base64 | varchar(255) | YES | | NULL | | | user_generated_video_id | int(11) | YES | | NULL | | | title | varchar(255) | YES | | NULL | | | position | int(11) | YES | | NULL | | | messages | text | YES | | NULL | | +-------------------------+--------------+------+-----+---------+----------------+
我不知道是否有什么我可以尝试进一步诊断问题。 或者我应该尝试改变configuration作为可能的解决scheme。 基本上查找或更新需要大约8-12ms，但创build或销毁语句需要10秒钟才能完成。
这很可能是由于创build或删除行时索引必须更新。 也许你可以在慢节奏的时候考察一下top的结果，看看是不是硬盘会让你放慢速度。 当然，这也可能是由于mysqlconfiguration的优化不佳所致。
我想这个原因可能在你没有在这里显示的键上。 更新多个键可能需要一些时间，如果在只读操作中不更改这些列，则不必在UPDATE上进行更新。
你的索引几乎是表大小的10％，每个表更新需要重写，而且确实需要一些时间。
所以尽量减less一些合理的金钥。