EF6 with MySQL Connector 6.9.5 中 LIKE 查询参数化异常的解析与解决方案
在使用 EF6 配合 MySQL Server 5.6 及 MySqlConnector 6.9.5 进行开发时，遇到了一个关键问题：当通过变量传递字符串进行 Contains 查询时，生成的 SQL 使用了占位符形式的参数（如 %p__linq__0%），而非实际值，导致查询逻辑失效或性能下降。
以下是复现问题的代码片段：
var username = "admin";
var lst = userService.GetQuery().Where(p => p.UserName.Contains(username));
foreach (var user in lst)
{
Console.WriteLine(user.Id);
Console.WriteLine(user.UserName);
}
此时生成的 SQL 为：
SELECT
`Extent1`.`Id`,
`Extent1`.`CaeateBy`,
`Extent1`.`CreateDate`,
`Extent1`.`CreateIp`,
`Extent1`.`DefualtLang`,
`Extent1`.`Descripton`,
`Extent1`.`IsSystem`,
`Extent1`.`LastEditBy`,
`Extent1`.`LastEditDate`,
`Extent1`.`LastEditIp`,
`Extent1`.`Password`,
`Extent1`.`RealName`,
`Extent1`.`StatusId`,
`Extent1`.`TypeId`,
`Extent1`.`UserName`
FROM `User` AS `Extent1`
WHERE `Extent1`.`UserName` LIKE '%p__linq__0%'
可见，参数未被正确展开，而是以占位符形式插入，这通常意味着 EF6 的 LINQ 到 SQL 转换机制未能对动态变量执行有效的常量折叠。
然而，若直接写入字面量，如：
var lst = userService.GetQuery().Where(p => p.UserName.Contains("admin"));
则生成的 SQL 正确无误：
WHERE `Extent1`.`UserName` LIKE '%admin%'
根本原因分析
该现象源于 EF6 与 MySQL Connector 之间对表达式树中参数处理的差异。当变量作为参数传入 Contains 时，EF6 在构建 SQL 时无法将其识别为可内联的常量，从而将整个表达式视为参数化绑定，最终由 MySQL Connector 以参数形式注入。但由于 LIKE 模式中包含通配符，且参数名被编码为 p__linq__0，MySQL 并不能正确解析其含义，导致匹配失败或语义错误。
解决方案
通过在变量上添加 .Trim() 或 .ToLower() 等方法调用，可以触发 EF6 的表达式重写机制，使该表达式不再被视为纯参数引用，而被转换为函数调用形式。
例如：
var username = "admin";
var lst = userService.GetQuery().Where(p => p.UserName.Contains(username.Trim()));
生成的 SQL 变为：
WHERE (LOCATE(TRIM('admin'), `Extent1`.`UserName`)) > 0
虽然不再是 LIKE，但 LOCATE 在 MySQL 中用于子串查找，效率高于模糊匹配，尤其在索引可用时表现更优。
补充说明
LOCATE是 MySQL 内置函数，用于返回子串首次出现的位置。- 若需保留
LIKE语法，可手动构造表达式，或通过自定义函数提供映射。 - 建议在涉及字符串搜索的场景中，优先使用
Trim()、ToLower()等操作强制表达式"非参数化"，避免因参数解析异常引发潜在错误。
总结
此问题并非数据库驱动本身的缺陷，而是由于 EF6 表达式树分析机制对复杂参数处理不够智能所致。通过简单地引入一次字符串处理操作，即可绕过该限制，并获得更高效的查询方式。
