今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug:在 5.1 版本中,Innodb 存储引擎如果使用autocommit=0的情况下,单条SQL在执行过程中如果异常中断的话,事务完整性可能无法保证,不论是STATEMENT还是MIXED的binlog_format,都存在相
今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug:在 5.1 版本中,Innodb 存储引擎如果使用autocommit=0的情况下,单条SQL在执行过程中如果异常中断的话,事务完整性可能无法保证,不论是STATEMENT还是MIXED的binlog_format,都存在相同的问题,可以重现,屡试不爽。
测试环境如下:
OS:SunOS 5.10 Generic_137138-09
DB:MySQL 5.1.31/32-log Source distribution
binlog_format:MIXED/STATEMENT
tx_isolation:REPEATABLE-READ
测试脚本如下:
[root@dc-5 /tmp]#cat deletetest.sh
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -e"set autocommit=0;delete from test.test;"
[root@dc-5 /tmp]#cat killtest.sh
#/bin/sh
mysqladmin -uroot processlist |grep "admin"|awk '{print $2}'|xargs mysqladmin -uroot kill
将删除的脚本放到后台执行,然后执行kill脚本:
[root@dc-5 /tmp]#time ./deletetest.sh &
[1] 6708
[root@dc-5 /tmp]#./killtest.sh
ERROR 1053 (08S01) at line 1: Server shutdown in progress
real 0m2.901s
user 0m0.007s
sys 0m0.007s
[root@dc-5 /tmp]#
[1]+ Exit 1 time ./deletetest.sh
到Master 和 Slave 两端分别检查数据,看上去很正常:
root@dc-5 : (none)01:35:43> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.71sec)
root@dc-6 : (none)01:36:01> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.69sec)
我们再将set autocommit=0拿掉试试看,也就是允许系统自动提交:
[root@dc-5 /tmp]#cat deletetest.sh
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -e"delete from offer1.test;"
[root@dc-5 /tmp]#time ./deletetest.sh &
[1] 6722
[root@dc-5 /tmp]#./killtest.sh
[root@dc-5 /tmp]#ERROR 1053 (08S01) at line 1: Server shutdown in progress
real 0m2.462s
user 0m0.006s
sys 0m0.007s
[1]+ Exit 1 time ./deletetest.sh
再检查 Master 和 Slave 两端的数据:
root@dc-5 : (none)01:40:30> selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
| 887377 |
+----------+
1rowinset(1.66sec)
root@dc-6 : offer101:44:05> selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.70sec)
Master 和 Slave 两端数据居然出现不一致,在 Master 端已经删除掉了部分数据,在 Slave 端却没有任何变化。执行 deletetest.sh 脚本前后检查 Master 的 Binary Log(SHOW Master STATUS),没有任何变化。这个 Bug 简直是太扯淡了,数据完全没有事务完整性可言了啊。
原文地址:MySQL5.1 中Innodb事务完整性Bug, 感谢原作者分享。

MySQL和SQLite的主要區別在於設計理念和使用場景:1.MySQL適用於大型應用和企業級解決方案,支持高性能和高並發;2.SQLite適合移動應用和桌面軟件,輕量級且易於嵌入。

MySQL中的索引是數據庫表中一列或多列的有序結構,用於加速數據檢索。 1)索引通過減少掃描數據量提升查詢速度。 2)B-Tree索引利用平衡樹結構,適合範圍查詢和排序。 3)創建索引使用CREATEINDEX語句,如CREATEINDEXidx_customer_idONorders(customer_id)。 4)複合索引可優化多列查詢,如CREATEINDEXidx_customer_orderONorders(customer_id,order_date)。 5)使用EXPLAIN分析查詢計劃,避

在MySQL中使用事務可以確保數據一致性。 1)通過STARTTRANSACTION開始事務,執行SQL操作後用COMMIT提交或ROLLBACK回滾。 2)使用SAVEPOINT可以設置保存點,允許部分回滾。 3)性能優化建議包括縮短事務時間、避免大規模查詢和合理使用隔離級別。

選擇PostgreSQL而非MySQL的場景包括:1)需要復雜查詢和高級SQL功能,2)要求嚴格的數據完整性和ACID遵從性,3)需要高級空間功能,4)處理大數據集時需要高性能。 PostgreSQL在這些方面表現出色,適合需要復雜數據處理和高數據完整性的項目。

MySQL數據庫的安全可以通過以下措施實現:1.用戶權限管理:通過CREATEUSER和GRANT命令嚴格控制訪問權限。 2.加密傳輸:配置SSL/TLS確保數據傳輸安全。 3.數據庫備份和恢復:使用mysqldump或mysqlpump定期備份數據。 4.高級安全策略:使用防火牆限制訪問,並啟用審計日誌記錄操作。 5.性能優化與最佳實踐:通過索引和查詢優化以及定期維護兼顧安全和性能。

如何有效監控MySQL性能?使用mysqladmin、SHOWGLOBALSTATUS、PerconaMonitoringandManagement(PMM)和MySQLEnterpriseMonitor等工具。 1.使用mysqladmin查看連接數。 2.用SHOWGLOBALSTATUS查看查詢數。 3.PMM提供詳細性能數據和圖形化界面。 4.MySQLEnterpriseMonitor提供豐富的監控功能和報警機制。

MySQL和SQLServer的区别在于:1)MySQL是开源的,适用于Web和嵌入式系统,2)SQLServer是微软的商业产品,适用于企业级应用。两者在存储引擎、性能优化和应用场景上有显著差异,选择时需考虑项目规模和未来扩展性。

在需要高可用性、高級安全性和良好集成性的企業級應用場景下,應選擇SQLServer而不是MySQL。 1)SQLServer提供企業級功能,如高可用性和高級安全性。 2)它與微軟生態系統如VisualStudio和PowerBI緊密集成。 3)SQLServer在性能優化方面表現出色,支持內存優化表和列存儲索引。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

MantisBT
Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境

Safe Exam Browser
Safe Exam Browser是一個安全的瀏覽器環境,安全地進行線上考試。該軟體將任何電腦變成一個安全的工作站。它控制對任何實用工具的訪問,並防止學生使用未經授權的資源。

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)