MySQL prepare statement速度的测试思考

最近一直纠结于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引擎性能优化