mysql tidb 刪除延遲 tidb使用坑記錄

1、對硬碟要求很高，沒上ssd硬碟的不建議使用

2、不支援分割槽，刪除資料是個大坑。

解決方案：set @@session.tidb_batch_delete=1;

3、插入資料太大也會報錯

解決方案：set @@session.tidb_batch_insert=1;

4、刪除表資料時不支援別名

delete from 表名表別名 where 表別名.col = '1' 會報錯

5、記憶體使用有問題，go語言導致不知道**機制什麼時候運作。記憶體使用過多會導致tidb當機(這點完全不像mysql)

測試情況是，32g記憶體，在10分鐘後才**一半。

6、資料寫入的時候，tidb壓力很大, tikv的cpu也占用很高

7、不支援gbk

8、不支援儲存過程

9、列數支援太少，只支援100列，和oralce/mysql的1000列少太多(oracle 最大列數為 1000；mysql對於每個表具有4096個列的硬限制, 其中innodb每個表的限制為1017列, 最大行大小限制為65,535位元組)

外面文章的一些建議

3tikv＋3pd＋2tidb

在有了 tispark 之後，我們便利用 tispark 將中間表快取為 spark 的記憶體表，只需要將最後的資料落地回 tidb，再執行 merge 操作即可，這樣省掉了很多中間資料的落地，大大節省了很多指令碼執行的時間

在查詢速度解決之後，我們發現指令碼中會有很多針對中間表 update 和 delete 的語句。目前 tispark 暫時不支援 update 和 delete 的操作(和 tispark 作者溝通，後續會考慮支援這兩個操作)，

最後，關於實時的排程工具，目前我們是和離線排程一起進行排程，這也帶來了一些問題，每次指令碼都會初始化一些 spark 引數等，這也相當耗時。在未來，我們打算採用 spark streaming 作為排程工具，

每次執行完成之後記錄時間戳，spark streaming 只需監控時間戳變化即可，能夠避免多次初始化的耗時，通過 spark 監控，我們也能夠清楚的看到任務的延遲和一些狀態，這一部分將在未來進行測試。