SPM中 使用 limit ‘?’ 或 limit … 都会报错，无法创建。
binding语句如下
SPM limit binding报错 (935 字节)
我今天尝试使用网络抓包对原始SQL进行捕捉，初步看未发现原始SQL带有limit
你不能只针对这个SQL是否包含来判断的，比如：
set sql_select_limit=1000;
select * from tableA where a=1;
这样的方式来设置session变量，你SQL当然就看不到limit 了。
1 个赞
经过我们这边的测试，如果是在设置了session 的sql_select_limit变量，即使在binding的时候使用limit，一样没有办法命中binding的。所以暂时不考虑这种方式绕过了。
麻烦你这边进行下面的方式排查：
1、按照你上面抓包的方式开启抓包，然后重启一个你们的应用程序，通过关键字，检索是否包含sql_select_limit的关键字。
2、先对简单的SQL 进行一个binding，比如：select * from table where a=1 类似的SQL，然后使用你们连接数据库的驱动，比如jdbc等，写一个简单的程序，看是否可以命中。
3、通过使用你们的驱动，写一个简单的程序，执行SQL：show variable like ‘%select_limit%’ ，查看返回的值。
麻烦查下，来源是否框架导致的。
1、是否来自何种框架暂时无法确定。
2、这个SET 之后跟着的SQL是不是本主题中的慢SQL 还得继续分析报文，后续反馈。
3、程序侧目前直接写死 use index （正确索引），看看能不能规避，后续反馈。
1、这是一个已知的BUG，已经合并到master了，还没最后发布，可以关注下后续版本的更新。
2、这个BUG是由于设置了session的sql_select_limit变量，导致即使binding了，但是不会执行binding。
3、issue 链接：https://github.com/pingcap/tidb/issues/27949
V5.1.x和V5.2.x 当前最新版本是否也存在此BUG？
Master 里面也才这周才合并，下周开始会往低版本里面 cherry pick
其实跳开binding生效不生效另说，关键是SQL因为limit出现，导致优化器的选择出了那么大的偏差，核心问题在这里，至于SPM那都是亡羊补牢的手段，不SPM岂不是更好。
查询优化器选择执行计划有很多因素决定的，现在就要去到另外一个问题。你的执行计划为什么不是最优的。有可能是统计信息不准确导致的。这个就要你提供下这个SQL的执行计划了。
表健康度我之前也看过是100的，优化器飘忽不定也是老问题了，有时候不走正确索引再怎么analyze table它也不走，好难一一举例，不然也不会在V5.2刻意强调更激进的统计信息算法了。
我目前很依赖SPM以及修改原始SQL指定索引。
花里胡哨 五花八门的选择都有。
注：以下截图与本贴子主题无关！！！
是在会话显示设置sql_select_limit参数后才会影响binding使用把， 没有设置使用分配的默认值大小不会产生影响吧,
目前是的。这个后续会fix掉。
不显示设置时show variable也能看见该参数为什么没有影响binding？如果把显示设置的值设置成和默认18446744073709551615一样大是否也会有影响？
- 如果你的问题已解决：
- 如果你自己排查解决了，请附上你的解决方案，对自己的方案标记【对我有用】。
- 如果别人帮助你解决了问题，那么请选择【最有价值】的回复，标记为【对我有用】，对帮助你的人，也是一种嘉奖和赞赏。
- 被标记了【对我有用】的问题，才能被搜索到，这样子也能帮助他人更高效地找到答案。标记了【对我有用】还能获得 5 积分，5 经验值。
- 如果你的问题还没有解决，请继续追问及反馈你遇到的问题。