fix: Correct ORDER BY parameter handling in count queries (#868)

[pagehelper]

问题描述

修复 Issue #868：当 ORDER BY 子句中包含参数绑定（如 #{param}）时，如果 PageHelper 在生成 count 查询时优化掉 ORDER BY，会导致 JDBC 参数位置不匹配，从而引发错误。

原 PR #869 的问题：

• 简单地判断只要存在 ORDER BY 就返回 isSimpleCount = false
• 这会导致所有包含 ORDER BY 的查询都无法使用简单 count 优化，过于严格

正确的解决方案：

• 只有当 ORDER BY 包含参数占位符（?）时才不能优化
• 普通的 ORDER BY（如 order by id）可以安全地在 count 查询中移除

修改内容

1. 核心逻辑修正

修改 isSimpleCount 方法，使用已有的 orderByHashParameters 方法判断 ORDER BY 是否包含参数：

//#868 Cannot use simple count when ORDER BY contains parameters
//If ORDER BY contains parameters, removing it will cause JDBC parameter mismatch
//Fixed by @pwdLight - https://github.com/pagehelper/Mybatis-PageHelper/pull/869
if (orderByHashParameters(select.getOrderByElements())) {
    return false;
}

2. 测试用例完善

关键改进：使用 #{} 参数绑定而不是 ${} 字符串替换

• ${} 是字符串替换，在 SQL 解析前就被替换，不会产生 ? 占位符
• #{} 是参数绑定，会生成 ? 占位符，这才是 Issue pageHelper使用分页时查询总条数sql错误 #868 真正要测试的场景

新增测试 SQL 使用 CASE WHEN 和参数绑定来模拟复杂的 ORDER BY 场景。

测试结果

✅ TestOrderBy 测试通过
✅ 完整测试套件通过（所有测试，无回归问题）

验证的场景

• ✅ ORDER BY 包含参数绑定 - 不优化，保留 ORDER BY
• ✅ ORDER BY 不包含参数 - 优化，移除 ORDER BY
• ✅ 没有 ORDER BY - 正常优化
• ✅ 所有现有测试通过 - 无回归问题

技术亮点

1. 使用已有方法：复用了项目中的 orderByHashParameters 方法，保持代码一致性
2. 保留贡献者信息：在注释中明确标注了原作者 @pwdLight 的贡献
3. 测试覆盖完整：既测试了包含参数的情况，也测试了不包含参数的情况
4. 正确的测试方式：使用 #{} 参数绑定而不是 ${} 字符串替换
5. 无额外依赖：使用项目已有的 HSQLDB 数据库
6. 向后兼容：所有现有测试都通过，无破坏性变更

---

Co-authored-by: pwdLight pwdlight@users.noreply.github.com
Closes #868