虽然最近为MySQL预处理API和常规API的速度问题而烦恼，但网上共识主张使用预处理API。 因为该SQL语句是预编译的。 然后，只需将参数传输到MySQL，就可以减少多次调用编译所需的时间和多次调用需要再次传输SQL的数据量。 但是基于这个原理，实际上应用场景是需要多次执行相同的SQL语句的情况。 在现在的应用场景中，如果每次都有数据来，而你又用自己的机制重新计算分表中的表名，那么每次都必须重新初始化stmt中的SQL语句。 这样的效率反而不如普通的API快。
因此，进行了测试。 实验结果大跌。 我意识到烦恼的地方是错的。 这两个API的插入速度相差不大，目前大多数数据库操作库都提倡使用预处理机制。 在我现在的想法中，preparestatement快是可以无视的。 MySQL最初在5.0版之前不支持预处理API机制，但现在正在成熟，如此成熟的API的效率
1 .提高代码可读性：占位符“？” 连接字符串格式，而不是使用的原始代码的SQL语句
2 .提高了传递SQL语句数据时数据类型的可靠性。 预处理参数指定数据格式。 在连接SQL语句字符串时不需要自己转动
3 .可以防止SQL注入：预处理函数内部有对特殊字符的处理，可以防止‘#’等特殊字符注入
基于这三点，并不是真正意义上的预处理真的有多快，而是迫切需要预处理的使用。 我烦恼的API效率问题完全是多余的，但真正影响数据库性能的是这个my.cnf参数配置： InnoDB引擎的性能优化