- InnoDB支持事务，意味着强业务支持性更好；可以回滚，也就意味着某些异常状态下仍能保持稳定性。而MyISAM不支持，相对来讲性能效率就更好，只用查询类的表就更适合该引擎。
- 但5.5版本开始就将InnoDB作为默认引擎，在最新的8以上版本中，更是取消了MyISAM并更新了InnoDB，优化了InnoDB的效率，那MyISAM就没什么存在的必要了。
- 最近使用MyIsql时出问题并不是AOP切面和事务配置的问题，结果是MyISAM的问题，踩了个坑半天都没反应过来，查了半天才搞懂。
- 以前总觉得小就是美，快就是好的想法应该变化，至少不能两全的时候稳定性比快和小重要得多。当时想update一个表结果范围错了，网上一顿查都没查明白，就觉得InnoDB真烂要是MyISAM导出方便不知道多少。而当时也是只想着往里面灌数据，反正就一个跟视频一块做的项目，人家干啥我干啥呗，结果回过头来写第一篇数据库才发现现实里面哪有那么多正好的数据给你看。
- 最后就是之前的事还是要多拿出来找问题，重复的项目一边就够了，多改多嚼，我在网上搜大多都是15，16年的坑，结果到现在了我还在犯，看落后的视频做落后的项目，真的脑残。
贴一个问题，我最近遇到，也是很老的：
一个商品有库存，假设只剩最后一件了，库存为1，如果此时有很多个人同时购买此商品怎么办，不可能让两个人都下单成功，库存为-1吧，所以这个在php + mysql中具体怎么解决呢？
商品的库存信息是不是单独做一个表与商品信息表关联起来比较好还是只用一张表好呢？http://segmentfault.com/q/1010000002600161
之前做电商项目的时候也碰见过这个问题但是当时没仔细想也没现在这么懂，回头一想这也是锁，索引上面自己没有理解透。
再贴上我认为比较好的解决方案：
-
并发转化为串行，通过队列或类似的手段消解并发，后台一个consumer依次扣减库存
-
并发&加锁，锁的位置可以在mysql或redis或任意自写sever等地方
-
不过其实，下单到支付还有一定成功率的，所以下单的地方就卡死的话可能由于用户放弃支付反而卖不完，所以这里会有一些非技术的问题需要考量（超卖/有货没卖出去/支付后砍单倾向哪个？），这个扣库存并发的问题不一定发生在下单时候
而且事实上作为一个电商平台我还是认为3是最优解，如果是自己做着玩的话那2是比较好的选择，当然也可以把扣库存留到后面，流程图加一项。
当然下面的回答也涉及到了redis内存加持久化，只不过redis目前还没学就先拿这个改一下看看效果。工程化的解决方法我也看了：https://my.oschina.net/cart/blog/368690#OSC_h1_22
第一篇文章，先说这么多，慢慢来。
原文：https://www.cnblogs.com/Fireset/p/12363321.html
如果您也喜欢它,动动您的小指点个赞吧
602392714
清零编程群