在《Drupal的MySQL過度膨脹，清理緩存、翻譯表》這篇2012年8月的博文中，提到有些非英文網站的locales_source表不斷變大的問題，當時在網上找了一些資料，臨時先用删除表中某些特征的數據來解決，半年後再次逐步變大導緻網站訪問困難，又編寫了一個自動删除表中記錄的腳本來解決，但始終是治标不治本。
這些天在對其它網站進行多語言擴充的時候，發現有些網站也有類似問題，都是locales_source中包含大量不需要進行翻譯的内容，再次查找資料并逐步調試，終于是找到問題的根源并可以解決了，有兩種情況：
- Drupal為每個調用t('source')函數但沒有在locales_source中找到source的情況添加一條記錄，如果t()函數使用錯誤，可能導緻大量不需要翻譯的詞進入locales_source，這時候隻要找到調用的地方，去掉不需要的調用就可以解決；
- 在非英語版本網站中使用Views，設置了header和footer，Drupal會自動對header和footer嘗試進行翻譯，如果locales_source表中沒有相應的内容就添加一條記錄，對于路徑加變量使用Views的情況，就有多少種路徑加多少條記錄了，這時候可以把header和footer中的内容轉移到專門的block中就可以解決。
這個問題困擾了我們很久，現在終于是解決了，也不需要再定期删除locales_source中膨脹的數據了！
2015年5月，一個數據量很大的新站china.youbianku.com，放在自己托管的服務器上很慢，轉移到雲服務器上依然很慢，打開devel檢查，發現是每個頁面的locale查詢耗費了15秒，也是上面說的這個問題1造成的，修改顯示模闆，去掉不必要的t函數翻譯，再清理locales_source無用的内容後，從60多萬條記錄變成幾千條記錄，網站速度打開正常，甚至不到1秒。
2016年8月補充：zip.postcodebase.com的locales_source有14000條記錄，删除location為null的以後，還有11000條記錄，但數據庫服務器負載依然高，再删除locales_target中lid字段内容在locales_source中找不到對應lid的記錄（約30萬删除10萬還剩下20萬），看到數據庫負載馬上就恢複正常了。删除語句：
delete from locales_target where lid not in(select lid from locales_source);
2019年7月補充：在Drupal 7 Performance: Blown up locales_source table這篇文章裡面看到可以用這樣的語句來删除locales_target中找不到對應翻譯的locales_source裡面的記錄：
DELETE locales_source FROM locales_source left join locales_target lt using (lid) where lt.lid is null
评论