在《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
评论