MYSQL强制转换为VARCHAR字段的十进制

我的客户给了我一个电子商务项目来修复一些错误。早期的dumb开发人员给出了价格字段VARCHAR datatype，而不是products表中非常明显的整数，因此下一组开发人员为了根据价格范围进行搜索，使用了

CAST（价格为十进制）

。 现在，我是第三个研究这个问题的人，我发现这个十进制的东西不仅在0-500的价格范围内起作用，而且在500-1000，1000-2000等所有其他的价格范围内都起作用

查询如下：

目前的查询是：

 SELECT * FROM tbl_product where status=1 and subcat_id='128' and
 price>'0' and price<='500' ORDER BY CAST(price AS DECIMAL(12,2)) ASC

从tbl_产品中选择*，其中状态=1，子类别id='128'和
price>'0'和price这里最好的选择是接受VARCHAR不是正确的数据类型。你的行动计划很简单

添加新列价格新小数（12,2）
将数据从price迁移到priceNew
确认priceNew中的数据正确后，删除price并将priceNew重命名为price
删除所有CAST（price AS DECIMAL）hackjob并开始将数字作为数字处理
将选择/更新/插入的任何内容更新为price，以确保其处理正确的新数据类型
从长远来看，这将大大减少您的头疼问题，并且将更加可靠/优化。它还允许MySQL正确地将其视为数字而不是字符串，因此基于该列选择范围的键/值将变得更有效。
我在计划B中考虑了这一点。实际上，还有许多其他字段本应为整数类型，但早期开发人员已为其提供了VARCHAR。因此，我想用正确的数据类型创建另一个镜像表，编写一个PHP脚本从错误的表中读取数据并插入正确的表中。你认为这是正确的方法吗？这样，我甚至不必用十进制（12,2）添加新的列。这需要完成，真的需要。这需要做一次，以获得正确的数据类型。数字通常应该是INT（或TINYINT/SMALLINT/MEDIUMINT）。货币通常应为十进制（x，2），其中x=通常在10-12左右。如果你看重精确性，就永远不要把货币放在浮动汇率中，因为最终你会开始损失便士。在select中，关键问题是您希望字符串（price）表现为数字，而事实并非如此。你可以
WHERE CAST（价格为十进制）谢谢，西蒙，我想我需要这样做。我最好向我的客户收费：）