☰

mySQL 数据库在 INSERT、DESTROY 上表现极差，但在 FIND 和 UPDATE 上表现良好

tag-icon • tag-icon mysql performance optimization bottleneck
mySQL 数据库在 INSERT、DESTROY 上表现极差，但在 FIND 和 UPDATE 上表现良好

我认为我遇到了数据库扩展问题。我现在有一张包含近一百万行的表，每当我们尝试创建新实例时，我们的 rails 应用程序似乎都会挂起。我注意到当我们销毁记录时也会发生这种情况。但是，查找和更新非常快。

以下是表格中的一些信息：

| 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    |                | 
+-------------------------+--------------+------+-----+---------+----------------+

我想知道我是否可以尝试调查以进一步诊断问题。或者我应该尝试更改配置作为可能的解决方案。基本上，查找或更新大约需要 8-12 毫秒，但创建或销毁语句将需要 10 秒以上才能完成。

答案1

这可能是因为在创建或删除行时必须更新索引。也许您可以查看速度缓慢期间%wa的结果top，看看是不是 HDD 拖慢了您的速度。当然，也可能是由于 mysql 配置优化不佳造成的。

答案2

我猜原因可能在于您未在此处显示的键。更新多个键可能需要一些时间，并且如果不更改这些列以及只读操作，则不必在 UPDATE 时更新它们。

您的索引几乎占表大小的 10％，每次更新表时都需要重写，这确实需要一些时间。

因此，请尝试将按键数量减少到合理的范围。

相关内容