用mysql自带函数有什么不好？
1.很可能造成where后的条件无法走索引
2.把一些php层面简单的业务逻辑交给mysql来做，加大了mysql的压力（尽管可能你看来执行一次sql语句影响很小），对小系统而言没什么。如果对于大型系统，那会是灾难。大型系统的瓶颈基本都在数据库层面难以扩展，php很容易的水平扩展，php不会是瓶颈，因此，尽可能的降低数据库的处理压力，包括减少查询次数通过cache来解决，减少每次查询的时间则通过索引以及尽可能的业务在php层面处理，mysql只做最基本简单的查询少使用自带函数。
那mysql自带函数为什么存在？
1. 比如一些数据初始化是可以用，或者存储过程等..
2. 小型系统可以使用mysql自带函数，反正没啥瓶颈
3. 不能因为大型系统不建议查询用自带函数就不提供，因为考虑到普遍的需求
比如php框架的ORM设计，很费资源又慢，大型系统也不建议用，小系统就随便用，方便又快速。
总结就是不能因为一些场景不建议用就不提供...方便快速的代价就是性能。
以上纯属个人观点...
每个工具都有自己的定位，以及特定的使用场景。如果不在其擅长的场景下使用很可能你会遇上很多的痛苦。下面尝试通过描述下mysql函数的使用场景来回答题主的问题。
先看看mysql的一些个性:
1：单表千万级别（优化到极致能达到亿级别）行记录存储，简单条件（最好条件上有索引，当然也需要看具体case）查询
2：mysql喜欢大内存（可以将大量的索引直接放到内存中），喜欢高性能IO（比如SSD）
3：高并发的时候，CPU资源消耗也是非常严重的。如果峰值请求的时候，给遇上一个mysql函数（需要CPU做计算），那就很可能因为一个简单mysql函数酿成了悲剧。mysql出事故的时候，load很容易飙到100+
下面再看我们系统的场景
1：mysql不是系统的瓶颈
该场景下可以随意的使用mysql提供的特性功能，例如msyql函数，多方便好用啊。较少了应用层的工作量。而且对你系统性能没有多大的影响。
举例说明：小型系统，请求量小，数据存储量小，mysql server内存充足，统计需求（一个sql跑一个晚上你也不担心）
2：mysql即将（或者正在）是系统的瓶颈
这个时候mysql最好仅仅当做存储来用，尽量不做任何额外的计算。优化的时候，会尽可能的把计算消耗的资源移到应用层去做。尽量保证mysql仅仅做储存工作。另外使用mysql函数很可能走不了索引，那个更悲剧了，这样系统更没办法抗住大并发。
用mysql存储过程有什么不好？
存储过程的优点主要包括以下几点：
第一点，性能提高。这是相对于不适用存储过程来说的，因为存储过程在创建的时候就编译好了，而后每次调用都不会再次编译，这相对于传统的SQL语句中每次调用都需要编译的情况来说，性能提高了何止一点两点。
第二点，重用性强。存储过程使用名字即可使用，也就是传说中的“一次编写，随便调用”。这样不仅提高了重用性，还减少了出错的几率，也会加快开发速度，可以说是一件非常好的事情。
第三点，减少网络流量。这一点对于小数据量的时候一般体现不出来，那么当数据量较大的时候，我们会发现由于使用存储过程比使用SQL语句会使用更少的字节数，因此它会降低传输的数据量。
第四点，安全性提高。由于存储过程也可以使用权限控制，而且参数化的存储过程可以防止SQL注入攻击，也在一定程度上保证了安全性。
第五点，灵活性增强。由于存储过程可以使用流程控制语句来编写，导致它有着很强的灵活性，可以根据实际情况来执行不同的SQL语句，而不是只能单纯的简单的执行命令。而且该存储过程还可以修改其逻辑而其他部分不用改变，也就是说，我们的表的结构改变了，我们只需要修改相应的存储过程即可，我们的Java或者PHP等程序不需要改变。
第六点，当业务复杂的时候，存储过程会减少工作量，为什么呢，原因很简单，如果我们不适用存储过程，那么就会导致我们先从数据库中取出来数据，然后经过计算，再放入到数据库中，这个开销还是蛮大的，这中间的开销包括我们的Java或者PHP程序连接数据库获取结果集等若干操作，如果我们使用了存储过程，那么就没有那么多事了，直接在mysql内就搞定了。
缺点：
第一点，工作量加大。这里并不是说我们把程序该做的事让mysql去做不好，而是mysql本身并没有很像样的IDE来开发我们的存储过程，我们很多时候还是需要手写，这样就会比较麻烦，而且存储过程的调试也是一个问题，没有很像样的调试工具。
第二点，优势不明显。运行速度上，对于大多数的语句缓存来说，编译sql的时间开销并不是很大，但是执行存储过程还需要检查权限等一些其他开销，所以，对于很简单的sql，存储过程并没有很大优势。
第三点，赘余功能。对web程序来说，我们连接数据库的用户往往就是同一个，不需要太多的安全机制，所以，对于安全上的检测看上去很好，实际上优点多余。
第四点，小型程序完全无用。对于小型web应用来说，它的使用价值就更小了，反而会拖累开发进度。
第五点，对于运维上。当我们的程序要更换数据库的时候，它的移植性相对于不适用存储过程要复杂一些，对于维护上，由于是在db端，因此比server端的程序更好维护一些。
参考：
3796
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
