周五下午，同事突然说有个存储过程要帮忙优化，就拿来看看，大概看了下：
数据库端需求：数据库中要存储一个AppID字段，对应一个Account可以自行设置自己的AppID（我就不从业务上多说了），
以前是根据逗号分隔符来存储，供前端展现的，展现和更新性能都没有问题。后台做运算时需要把这些逗号分隔符进行行转列同步给内存数据库。
随着业务量的增加，每个Account对应的AppID增加到了2W左右，与之带来了行转列的性能问题。
旧逻辑中是通过对存储AppID的逗号分隔符字段与App表进行Cross Join ,然后再用SubString来实现行转列。
在旧逻辑的基础上去掉Cross Join 的部分:
SET @app='**********'; -- 不贴出来了，2万多个逗号分隔符的ID
SELECT CAST(CAST(SUBSTRING_INDEX(SUBSTRING_INDEX(@app,',',AppID),',',-1) AS CHAR(10))AS SIGNED) AS AppID FROM `tbl_app`;
性能由原来的42s上提高到33秒,还是不行，离目标的3s之内相差甚远啊。
印象中这么小的数据量不至于耗费这么长时间，用.NET中的string.split方法试了一下，瞬间不到1s就拆分完毕。
现在储过程中解决了）。用的都是mysql的系统函数，评现在自己的技能（现在还没学会在mysql 中调用其它类型代码的方法，如果是MSSQL，早就写应用程序集成在存储过程中了）
计划周末查查怎么在Mysql中自定义函数算法呢，结果突发奇想了一种方法，其实行转列最后存储的是表，如果使用replace语法生成可以批量插入的Insert语法，完全可以实现。果断一试，1s内完成。
既然优化至3s内的需求实现了，就不着急了，不过还是对mysql字符处理函数的实现方式很好奇，有时间研究下。
现在回想起来，自己是陷入行转列非要用While循环之类的逐个剥离，这样高效，一直这样做，换了一种思考方式，答案可能离你不远。
这个行转列的方法也跟大家分享一下，希望没浪费大家时间。