從某個時間開始，Cat監控到的數據發現，正式環境的Insert 表很慢，數據庫用了AlwasON高可用(1個備庫做了實時同步），特別是每天早上9:00--11:00,做活動的時候，下單的insert需要1秒，有些有3秒的，而且是大量出現
很多簡單的insert也有。從8月份就一直就有問題，嚴重影響業務 ，當時還記錄了： https://www.cnblogs.com/zping/p/9510485.html
自己還特意問了同行，有沒有遇到這樣的情況，結果說是同步改成異步。
查看數據庫監控SQL：
大量HADR_SYNC_COMMIT這樣的等待事件， 網上找到的解決辦法：https://www.sqlshack.com/sql-server-wait-type-hadr-sync-commit/
1，AlwasON環境下，從實時同步改成異步
2，提示網絡帶寬
3，將大的事務改成小事務
4，減少索引和修改的數據量
5，拆分數據庫
這些解決辦法 1，第一改成異步，業務部門不同意，因為有些業務是讀的這個庫，需要實時同步，
2，直接網絡帶寬，局域網的帶寬限制沒有用完
3，將大的事務改成小事務，業務上沒有具體的操作性
4，減少索引，后來的確刪除了4個覺得不太重要的索引，但是還沒變化
5，拆分庫，就是把表拆到其他庫里
這5個辦法，當前面4個辦法沒多大操作空間，最后只能拆分出表，讓程序去修改。根據監控，有4個表拆出來后，這4個表的寫入是好了，但是下單還是慢。后來說只有把下單的表獨立出來就會好
也想找其他原因，也咨詢了其他的同行，有沒有出現HADR_SYNC_COMMIT的解決辦法，結果他們沒出現這樣的問題。
對應比較官方的建議，我一直沒有懷疑， 而且后來還懷疑是否： 1，Cat數據不准 2，網絡是否不穩定 3，接的數據庫insert方法有性能問題等待
懷疑這個懷疑那個引起的性能問題。
因為主庫一直有監控他的性能差的sql，一旦出現性能sql，就會立馬修改。主庫不會有什么性能問題。對比了一下2017年8月份的監控數據，發現當時HADR_SYNC_COMMIT 的等待事件很少，
沒有現在這么頻繁。
是因為數據量增長的原因？
和去年的訂單表數據對比，數據量增長了50%左右，有個表達到了8千萬條數據，是數據量增長的原因？
如果是數據量增長的原因，那為何是在做活動的高峰才出現問題。
后來查詢備庫的錯誤日志，大量發現下列錯誤：
網上查：https://blogs.msdn.microsoft.com/joaol/2008/11/20/sql-server-checkpoint-problems/
是 checkpoint problem問題，這里的提交是0.18MB的速度， 這么慢。是硬盤慢，用CrystalDiskMark 6.0 工具測試了一下硬盤性能，沒有特別的問題，也讓人看了服務器的硬盤，都沒有問題
這個文章也介紹： https://www.sqlservercentral.com/Forums/Topic1363610-2799-1.aspx
To resolve this issue, you have several options:
1. dirty fewer pages (drop extra indexes, use compression, tune queries, etc). Fewer dirty pages means less work each checkpoint.
2. reduce IO load overall (Add memory to reduce reads/sec, move busy tempdb to different drive, tune queries, etc)
3. increase IO write capacity (extra spindles in SAN, add SSD's, switch from Raid-5 to Raid-10, etc)
4. smooth out checkpoint's IO load (set a really high recovery interval and perform manual checkpoints. Don't go here until you've got a really good handle on the perfmon counters above and can prove that this helps.)
上面的解決辦法： 就是減少IO，提示硬盤的IO能力，換成SSD的。 但根據實用的沒有。因為也不可能備庫換服務器。
沒辦法查了一下備庫的監控的SQL：
大量的： IO_COMPLETION，PAGEIOLATCH_SH，PAGEIOLATCH_EX，其中PAGEIOLATCH_SH的事件出現最多，
PAGEIOLATCH_SH： 經常發生在用戶正想要去訪問一個數據頁面，而同時SQL Server卻要把這個頁面從磁盤讀往內存。
PAGEIOLATCH_EX：經常發生在用戶對數據頁面做了修改。SQL Server要向磁盤回寫的時候，意味着寫的速度跟不上。
IO_COMPLETION： 這種等待類型表示數據文件中的各種同步讀和寫操作，這些操作與表無關，並且從事務日志中讀取。
pageiolatch是為了數據的異步訪問。比如說我們想讀取一個page，但是它不內存中，那么sql server會首先在內存中為這個page空出一塊空間，並且加上ex_latch，然后在這個page真正從disk讀取到內存當中之前，其他線程不能對這片內存進行操作。因為異步操作，所以這個線程會去訪問這個page，此時申請sh_latch，但是與之前的ex_latch，最終導致自己被自己阻塞了。這就是pageiolatch_sh。
這一切說明，備庫的IO性能有問題。
是什么導致備庫的IO性能異常？
特意查了備庫的查詢的SQL，有大量的查詢慢的SQL，很耗CPU的：
這些SQL有些查詢特別大的表，很耗CPU，直覺告訴我，這些sql有問題，后來發現這些sql也是從8點左右開始查詢，是為了監控業務數據的，咨詢了一下，可以停掉，還有一些有性能的sql優化了一下，有些查詢如果
不讀這個實時備庫，就遷移到異步讀庫。修改了一圈后，有問題的SQL少了很多。 今天早上9；00開始的活動搶購，insert慢的問題沒有出現，自己都覺得不可思議，困擾我們近1年的DML操作慢的問題解決了。
總結：
1，太教條，就依據等待事件的解決辦法。
2，只關注主庫的性能差SQL，未監控實時備庫的性能差的SQL，實時備庫有時會拖主庫的后腿
3，SQL Server的錯誤日志的信息要時常看看。