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 作者溝通，后續會考慮支持這兩個操作），
我們便嘗試了兩種方案，一部分執行類似於 Hive，采用 insert into 一張新表的方式來解決；另外一部分，我們引入了 Spark 中的 Snappydata 作為一部分內存表存儲，
在 Snappydata 中進行 update 和 delete，以達到想要的目的。因為都是 Spark 的項目，因此在融合兩個項目的時候還是比較輕松的。
最后，關於實時的調度工具，目前我們是和離線調度一起進行調度，這也帶來了一些問題，每次腳本都會初始化一些 Spark 參數等，這也相當耗時。在未來，我們打算采用 Spark Streaming 作為調度工具，
每次執行完成之后記錄時間戳，Spark Streaming 只需監控時間戳變化即可，能夠避免多次初始化的耗時，通過 Spark 監控，我們也能夠清楚的看到任務的延遲和一些狀態，這一部分將在未來進行測試。