在MySQL 5.7中,定义如下的表
CREATE TABLE `person` (
`person_id` bigint(20) NOT NULL AUTO_INCREMENT,
`name` varchar(64) DEFAULT NULL,
PRIMARY KEY (`person_id`),
KEY `ix_name` (`name`)
) ENGINE=InnoDB CHARSET=utf8
然后我们准备了两条记录进行测试,name
字段(具有varchar类型)的值是
分别。
案例1
select * from person where name = 123456789123456789-1;
请注意,我们在where子句中使用数字而不是字符串。返回名称为123456789123456789
的记录,似乎最后的-1
被忽略了!
此外,我们添加了另一个名称为123456789123456788
的记录,这一次上面的选择返回了两个记录,包括123456789123456789
和123456789123456788
;
输出看起来很奇怪!
案例2
select * from person where name = 123456789123456789-123456789123456788;
我们可以获得名称为1
的记录,在这种情况下,-
似乎是负运算符。
为什么在两种情况下-
的行为如此不同!
答案 0 :(得分:2)
我不能立即告诉您name
的类型是什么,但是对于比较操作,我们几乎可以肯定,对于mysql,大多数“更普通的” data type conversion rules都无法使用,并且最终在:
在所有其他情况下,将参数作为浮点数(实数)进行比较。
因为比较的一个参数(func getUrlFromPHAsset(asset: PHAsset, callBack: @escaping (_ url: URL?) -> Void)
{
asset.requestContentEditingInput(with: PHContentEditingInputRequestOptions(), completionHandler: { (contentEditingInput, dictInfo) in
if let strURL = (contentEditingInput!.audiovisualAsset as? AVURLAsset)?.url.absoluteString
{
PRINT("VIDEO URL: \(strURL)")
callBack(URL.init(string: strURL))
}
})
}
)是字符串类型,另一个是数字类型,所以没有其他匹配项。因此,两者都将转换为浮点数,并且浮点数类型的精度没有太多位数。当然小于将123456789123456789和123456789123456788表示为两个不同数字所需的18。
答案 1 :(得分:0)
看这里:
SELECT person_id, name, name + 0.0, 123456789123456789-1 + 0.0, name = 123456789123456789-1
FROM person
ORDER BY person_id;
也许,在比较name = 123456789123456789-1
之前,MySQL如我在select中所示将name
和123456789123456789-1
转换为DOUBLE
。因此一些数字丢失了。
Demo。