好多年不做服务器项目了，最近几个项目均和服务器有关，出现很多性能相关问题，其中一个项目涉及到这么一个业务，拿出来和大家分享下。
业务大致为：刷身份证过检，设备端生成一个过检记录id,需要把身份证文字信息和身份证图片信息分别上传到服务器S1和图片服务器S2，其中服务器数据库中身份证图片信息保存的是身份证照片在图片服务S2上的url。
如果强制必须文本信息在服务器S1上传成功后，再上传身份证图片，势必会影响图片上传时间。如果不做这个强制限制，上传图片url和文字信息入库时间先后就不能确定，url数据和文字信息在服务器数据库中是执行insert还是update就无法确定了，此时就必须处理insert失败返再重新进行update操作，这个时候可以考虑使用存储过程了。
在使用存储过程的问题上，和服务器端研发进行讨论决定是否使用存储过程，所以使用与否我们需要了解下存储过程的优缺点。
优点：
1. 运行速度：对于很简单的sql，存储过程没有什么优势。对于复杂的业务逻辑，因为在存储过程创建的时候，数据库已经对其进行了一次解析和优化。存储过程一旦执行，在内存中就会保留一份这个存储过程，这样下次再执行同样的存储过程时，可以从内存中直接调用，所以执行速度会比普通sql快。
2. 减少网络传输：存储过程直接就在数据库服务器上跑，所有的数据访问都在数据库服务器内部进行，不需要传输数据到其它服务器，所以会减少一定的网络传输。
3. 可维护性：存储过程有些时候比程序更容易维护，这是因为可以实时更新DB端的存储过程。 有些bug，直接改存储过程里的业务逻辑，而不用修改程序端代码。
4. 增强安全性：提高代码安全，防止 SQL注入。这一点sql语句也可以做到。
5. 可扩展性：应用程序和数据库操作分开，独立进行，而不是相互在一起。方便以后的扩展和DBA维护优化。
缺点 ：
1. SQL本身是一种结构化查询语言，但不是面向对象的的，本质上还是过程化的语言，面对复杂的业务逻辑，过程化的处理会很吃力。同时SQL擅长的是数据查询而非业务逻辑的处理，如果如果把业务逻辑全放在存储过程里面，违背了这一原则。
2. 如果需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新调用，等等，这时候估计会比较繁琐了。
3. 开发调试复杂，由于IDE的问题，存储过程的开发调试要比一般程序困难，不过这个对于有数据库功底的研发来说调试不是问题。
4. 没办法应用缓存。虽然有全局临时表之类的方法可以做缓存，但同样加重了数据库的负担。如果缓存并发严重，经常要加锁，那效率实在堪忧。
5. 不支持群集，数据库服务器无法水平扩展，或者数据库的切割（水平或垂直切割）。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。
总结：
1. 适当的使用存储过程，能够提高服务器性能。
2. 存储过程不应该大规模使用，DBA应该在设计与维护数据库时需要均衡考虑。
3. 随着众多ORM 的出现，存储过程很多优势已经不明显。
4. 结合项目业务实际，从业务逻辑简单的数据库操作不建议使用存储过程，复杂对数据实时性要求比较高，可以考虑从存储过程触发器上进行设计优化。
回到我们的这个项目业务上看。使用与否也需要结合客户是否对身份证图片信息实时性是否要求很高。最后与项目产品经理确认，身份证图片信息可延迟离线上传，那么完全可以不使用存储过程了。
