今天跟大家唠唠我昨天遇到的一个糟心事儿，关于“并非所有变量都已绑定”这个错误，搞我半天才弄明白，现在分享出来，希望能帮到大家。
事情是这样的，昨天在搞一个数据迁移的脚本，要从一个数据库导数据到另一个数据库，用的是Python，数据库是MySQL。脚本写好后，屁颠屁颠地跑起来，结果跑一半就报错，报的就是“ORA-01008: 并非所有变量都已绑定”，当时我就懵，心想这啥玩意儿？
第一反应肯定是看代码，是不是SQL语句写错。我先把SQL语句拿出来，仔仔细细地检查一遍，语法没问题，参数也对得上，看着没毛病。但是报错信息明明白白地写着“并非所有变量都已绑定”，肯定还是SQL的问题，问题是，到底哪里有问题？
- 仔细排查SQL语句： 我把SQL语句里的占位符（就是那些%s、?之类的）跟后面的参数列表对着数，一个一个地对，确保数量一致。
- 检查参数类型： 检查传进去的参数类型是不是跟数据库字段类型匹配，比如字符串要用引号引起来，数字就不能有引号。
- 数据库连接： 看看数据库连接是不是有问题，用户名密码是不是正确，数据库是不是存在，权限够不够。
上面这些我都检查，但是，还是不行！ 崩溃！
开始怀疑人生
这个时候，我开始怀疑是不是Python的数据库驱动有问题，我用的是`pymysql`。于是我就去查`pymysql`的文档，看看有没有什么坑。结果，没发现什么特别的。然后我又去Stack Overflow上搜一下，果然有人遇到过类似的问题，但是他们的解决方案跟我遇到的情况不太一样。
柳暗花明
折腾半天，我决定换个思路，把整个流程再梳理一遍。突然，我意识到，我用的是`PrepareStatement`，就是预编译SQL语句，这样可以提高效率，防止SQL注入。但是，`PrepareStatement`有个坑，就是如果你在执行的时候，SQL语句里有占位符，但是你没有给它绑定值，就会报“并非所有变量都已绑定”这个错误。
我回过头去看代码，发现我确实有个地方疏忽。在循环插入数据的时候，我先`PrepareStatement`SQL语句，然后在循环里执行，但是，有个别情况下，循环里某个变量是空的，导致我没有给对应的占位符绑定值。就是这儿！
找到问题就好办，我加个判断，如果变量是空的，就跳过这回循环。再跑一遍脚本，OK！终于跑通！
总结
这回的经历告诉我，遇到问题不要慌，要一步一步地排查。特别是用到`PrepareStatement`这种预编译SQL语句的时候，一定要确保所有的占位符都绑定值。还有，代码一定要仔细检查，不要放过任何一个细节。希望我的这回分享能帮到大家，避免踩同样的坑。