记一次FIND_IN_SET的排序错误的bug

问题本身比较复杂，在TP5框架下，精简后是下面这句sql

select GROUP_CONCAT(name) FROM ims_region WHERE FIND_IN_SET(id,'430000,430800,430822') order by id asc

查询出来的name，没有按照id排序，也不是倒序，是乱的。

拿这句sql用本地的Navicat测试，结果是对的。

tp5下就一句代码Db::quert($sql);，所以也没啥好错误好排查的。于是想可能是tp5对这个sql有了什么内部的改造，所以造成顺序不对（但是确实也不应该，既然传的都是直接的sql了，tp5还去改它干嘛）

然后用原生的pdo方式从新连接，完全写原生的代码，结果是对的，印证了刚才的猜想。

$dsn='mysql:host=;dbname=;charset=utf8';
$link = new \PDO($dsn, '', '');
$query=$link->query($sql);
$result=[];
while ($row = $query->fetch(\PDO::FETCH_ASSOC)) {
	$result[] = $row;
}

本来想就这样吧，但是总感觉又连接了一次数据库别扭，就看了下tp5的文件，找到了获取连接的pdo对象的方法$link=Db::getPdo();

本来想大功告成准备睡觉，最后测试一下，发现用了tp框架的pdo对象，结果又是错的。看来问题是出在pdo的链接上，于是再找框架，反复测试，发现是pdo链接属性的这个作怪PDO::ATTR_EMULATE_PREPARES = false

改成true就好了（去掉也行，因为默认就是true）

但是为了防注入，这个属性基本都设置为false的，所以还是不改的好

所以就多连一次吧，浪费这么点效率总比不安全要好