Mysql order by 类型转换

 

起因:写sql order by一个字段,字段类型是varchar里面存储的是数字,要按数字大小排序,而不是按首字符出现先后顺序,这就需要转换

RDER
 BY
 CAST(
`pic_number`
 AS
 SIGNED)

and for reverse order

ORDER
 BY
 CAST(
`pic_number`
 AS
 SIGNED)
 DESC

And it worked like a charm!

Function is as simple to use as:

CAST(
expr AS
 type)

Other possible conversion types you may need are:

  • BINARY[(N)]
  • CHAR[(N)]
  • DATE
  • DATETIME
  • DECIMAL[(M[,D])]
  • SIGNED [INTEGER]
  • TIME
  • UNSIGNED [INTEGER]
当 `MySQL` 中的 `ORDER BY` 子句不生效时,可能是由以下几个原因导致的: ### 常见的原因及解决办法 1. **查询结果被缓存** 如果数据已经被缓存,并且排序没有强制应用到最终的结果集上,则可能会忽略 `ORDER BY` 操作。尝试添加 `SQL_NO_CACHE` 来避免这种情况: ```sql SELECT * FROM table_name SQL_NO_CACHE ORDER BY column_name ASC; ``` 2. **字段值存在 NULL** 当需要按某个列进行排序而该列包含大量空值 (`NULL`) 时,默认情况下 MySQL 可能将所有 `NULL` 放置在最前或最后(取决于顺序)。可以明确指定如何处理这些情况: ```sql -- 将 NULL 置于末尾 (ASC) SELECT * FROM table_name ORDER BY IF(column_name IS NULL, 1, 0), column_name ASC; -- 或者 DESC 排序类似调整 ``` 3. **分页与 LIMIT 的干扰** 使用了 `LIMIT` 进行分页操作时如果忘记加上对应的排序规则也可能出现问题;例如只写了部分语句如下的错误示例不会按照预期工作: ```sql SELECT ... WHERE condition LIMIT offset, rows; // 缺少 ORDER BY 部分会随机返回记录。 ``` 4. **索引覆盖限制** 若表上有合适的复合索引来支持直接访问满足条件的数据块,但未显式指出排序依据点位则可能导致优化器跳过实际排布步骤。 5. **拼接字符串或其他函数调用影响正常解析路径** 对某些复杂的表达式比如计算字段、时间戳转换等做二次加工后作为目标键值传入order by里头的话容易引发混乱状态。 6. **大小写敏感度配置问题** 字符串类型的比较受到字符编码设定的影响,在不同的数据库实例间同步迁移代码文件或者切换系统环境变量设置不当均会引起差异反应。 --- #### 解决建议总结: - 检查是否遗漏书写完整的 `ORDER BY` 子段名及其升降次序; - 明确对特殊状况像 `nulls first|last` 的额外声明需求; - 结合实际业务场景考虑是否有必要针对特定运算后的数值再重新规划优先级逻辑; - 查看当前服务器版本特性以及默认选项是否存在偏差从而引起异常现象发生;
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值