索引优化前先诊断瓶颈真的在系统本身，而非想当然去调优

面对”索引速度慢”这样的性能问题，一个容易踩的坑是立刻扎进具体的调优参数（换SSD、调线程池、改buffer size），但更靠谱的第一步其实是先判断瓶颈到底在哪里：如果拖慢整体流程的是从数据库读取原始文档（产生doc）的速度，那么问题根本不在Elasticsearch本身，无论怎么调Elasticsearch的参数都不会有实质改善，真正该优化的是数据库读取那一端。反过来，如果确认瓶颈确实在Elasticsearch索引这一侧，也不能默认就是硬件或参数不够，有真实案例是索引速度突然变慢，排查下来是新版本的IK分词插件本身出了问题，换掉分词插件问题就解决了——这类问题靠调硬件、调线程池参数是永远调不出来的，必须先定位到具体是哪个环节在拖后腿。这条经验背后是一个在任何性能优化场景都适用的原则：优化动作永远应该跟在”瓶颈定位”后面，而不是先入为主地假设瓶颈在某个组件、然后不断堆砌该组件的调优手段——如果诊断方向本身就错了，再精细的参数调优也只是在无关的地方做无用功，甚至可能因为盲目调整掩盖了真正的问题根源（比如分词插件的Bug）。