use*_*182 10 mysql innodb performance deadlock insert
我有一个流量非常高的网站，每小时可能会插入 1000 条新记录。
这一错误使网站瘫痪：
PDOException: SQLSTATE[40001]: Serialization failure: 1213
Deadlock found when trying to get lock;
try restarting transaction: INSERT INTO {location_instance}
(nid, vid, uid, genid, lid) VALUES (:db_insert_placeholder_0,
:db_insert_placeholder_1, :db_insert_placeholder_2,
:db_insert_placeholder_3, :db_insert_placeholder_4);
Array ( [:db_insert_placeholder_0] => 1059 [:db_insert_placeholder_1] =>
1059 [:db_insert_placeholder_2] => 0 [:db_insert_placeholder_3] =>
cck:field_item_location:1059 [:db_insert_placeholder_4] => 1000 )
如果 MySQL 无法处理这种类型的负载，我会感到非常惊讶。那么，我的问题是，这是一个数据库问题，我该如何配置 MySQL 才能处理这么多流量？
我在开发服务器上设置了我的网站副本，其中包含模拟添加到网站的内容负载的脚本。我正在运行带有 16GB RAM 的 Ubuntu、LAMP 堆栈。
诚然，我对数据库不是很了解。事实上，我从“apt-get install”完成后随附的默认 my.cnf 开始。表都是Innodb。你会推荐什么起始配置设置和方法来开始解决这个问题？
让我知道您可能需要更多信息。
谢谢
小智 11
您正在处理死锁，而不是性能瓶颈问题。
如果你每小时有一千条新记录，你离达到 MySQL 的极限还很远。MySQL 可以处理至少 50 倍的负载。
死锁是由应用程序代码引起的，而不是数据库服务器的错误。死锁无法在 MySQL 服务器端修复，除非在某些特定情况下。
InnoDB可以通过SHOW ENGINE INNODB STATUS在 MySQL 提示符下运行或使用mysql -uroot -p... -e "SHOW ENGINE INNODB STATUS".
但是，这只显示最后发生的死锁，没有死锁日志。
值得庆幸的是，有一个工具pt-deadlock-logger可以解决这个问题，它负责轮询InnoDB状态并在用新的死锁刷新之前保存所有详细的死锁信息。
这可能就像运行事务的代码的一部分一样简单：
insert into t1...
insert into t2...
commit;
而代码的另一部分以不同的顺序修改相同的表：
delete from t2 where...
delete from t1 where...
commit;
如果这两个事务同时运行，就会出现竞争条件：第一个事务不能修改，t2因为它被第二个事务锁定；而第二个事务同样被阻塞，因为t1被第一个事务锁定。MySQL 选择一个事务作为 INSERT/UPDATE/DELETE 失败的“受害者”。应用程序需要捕获该错误，然后重试该语句 - 可能在暂停之后以便其他事务有时间完成。与容量限制无关，只是不幸的时间安排可能会因代码的排列方式而加剧。切换事务 #2 中的 DELETE 或事务 #1 中的 INSERT，然后就不会有冲突 - 每个事务将等待访问它需要的表。
在 MySQL 5.6 中，您可以在启用innodb_print_all_deadlocks选项的情况下运行以收集有关 MySQL 错误日志中所有死锁（不仅仅是最近的死锁）的信息。
[强制性免责声明：我是 Oracle 员工。以上为个人观点，非官方说法。】