五月华斩_个人页

这种我见过很多用ORM整出上百SQL的case，当时就震惊了。其实菜单顶多就那几百项目，而且属于不怎么更新的内容。你完全可以考虑将菜单在程序启动之初就初始化成你想要的结构并缓存起来。顶多增加一个菜单改动的功能，在菜单调整之后直接更新数据库跟缓存。

你对事物提交和回滚的过程没整清楚。提交出错再回滚，那是说你在commit trans的时候出错了再回滚。回滚可以发生在你commit trans之前。比如一个sql执行出错。

这种写法sql注入妥妥的，看着就怕怕。

读写分离提升性能是有特定的应用场景的。不是万金油。比如都是大流量的写入操作，整个读写分离嘛用都没有。

这种的优化建议先看查询计划，而且单列索引在这个场景可以看得到是不会有啥好效果的。如何让执行计划走到index coverage
应该是一个思路。

其实可以根据需要在可读性跟高性能（其实微乎其微）做选择，可读性自然是用varchar更好。别人一看你的数据库内容就知道意思了。用tinyint貌似节省存储空间节省内存，其实我个人觉得这点性能的提升压根就不是数据库优化的重点。我肯定是优先选可读性。

这种多数是权限的问题吧？试试root用户来整整，或者grant当前用户create权限在bank表上

这种应该是先测试网络是否联通，比如自己用命令行连接下试试。如果能找到navicat的系统日志看看就最好。要习惯从日志中查问题。

这个数据统计要实时，要不要尝试下流计算？有很多方案基于离线的数据统计加上流计算处理在线实时数据。可以参考下

没有生成PID文件，会不会是设置的PID位置目录不存在？

这个next-key就是RR级别下才会出现的一个锁。虽然你指定where字句里面有id=2。貌似只要锁定一行记录就行了。其实RR的事务级别就要求不出现幻读。就是要避免你在id=2和id=3之间再插入其他的id=2的记录。所以他就会锁住id=2的next key中间的gap不知道我这么说是否清楚。

你说的锁表是明确提示死锁了吗?如果可以拿到死锁的日志信息。你可以根据死锁日志中提示的SQL分析其执行计划来估计死锁发生的原因。

分库分表的时候，一定是要明白你的数据库使用是受限的。比如查询的时候一定是要带上分库分表的键。然后表之间的连接都需要尽量避免。所以你提的分页，首先要看是不是在分库分表的键指明情况下的分页。当然也可以参考多份数据分库分表的情况。

传统的IT指哪些？是传统行业比如制造业里面的信息部门还是说开发行业软件的那部分？我个人跟作者有同感，我发现周围的朋友旧同事，但凡能力出类拔萃的都在往互联网行业跳。在这背后是资源的市场化配置，传统行业本身的增长趋势愈发缓慢，那作为其组成部分的信息部门自然也不会好到哪里去。这种情况我觉马云提的新制造可能是一个突破的口子。一个是制造业的自我革命，同时是支持他的信息系统的革命。现在很多saas软件我觉的是打破这种局面的一种尝试。通过软件的服务化可以打破传统行业的信息壁垒。让整个行业在数据和智能的支持下完成蜕变。但是这种蜕变依赖传统行业的自我成长已经不可能。只有外力才能促成蜕变。不知道这是不是马云的新制造的雏形：）。至于那种以往的开发行业软件的，出路我觉得应该从以往的产品/项目转型到软件服务。以往的产品/项目模式只是功能的售卖。未来应该是功能售卖是基础，数据的服务是核心。

基于数据的量级跟使用方式决定你的数据库架构选型。数据量决定了你的数据库架构的横向扩展的要求比如能不能分库分表。同时数据使用方式比如像网络上讨论的那般淘宝设立买家库跟卖家库。两者之间做数据同步。这种数据库架构就是通过分库分表加上多份数据来满足买家/卖家的查询操作，不过这种复杂架构同样会引入更复杂的挑战，比如双写，延时等各种挑战。

这个有点难以理解，在一个长事务中数据库连接断开。为啥会有一部分数据已经写进去了呢？事务中间的时候连接断开。那这个事务也不会提交啊。所以最先要确认的是不是压根就没begin transaction:)

多读多写多思考。多读的目的是开拓自己的视野，让自己具备举一反三触类旁通的能力。多写是脚踏实地，避免夸夸其谈纸上谈兵。多思考是融会贯通所读所写。

首先这种方式增加的工作量基本可以忽略不计。
其次在SOA/微服务中，这已经是行业一种基本共识了，如果你所在的开发团队没有使用，那你可能要考虑下你所在的团队是不是比较封闭。：）

你提到的更多的是技能集的丰富，我也是同样的经历，陆陆续续地接触过大数据相关的技术，但是都属于那种了解的程度，现在换个思路，通过业务场景的落地来推动自己技术的学习。我这边主要是数据挖掘相关的工作，结合现在的海量数据，高大上点的说法是机器学习，AI。这样对我来说跟以前对大数据的理解就不一样了，跟数据挖掘结合起来之后开始能体会到数据的价值。所以我的建议是将大数据跟业务结合起来。将大数据整个链条上的节点串起来去看。这样方向感更好点。整个纯属个人感觉：）

是否可以考虑opensearch的方案？opensearch支持直接从RDS增量更新数据。因为任意字段的查询，从业务场景上来说更像一个搜索引擎的场景。传统的数据库即便在有索引的情况下，也可能会碰到like %XXXX%的前后模糊匹配的场景。我们曾经使用opensearch解决了类似的任意字段前后端模糊匹配的业务场景。不过我们对实时性要求不高，分钟级别的都是可以接受的。这里分享下业务协同的经验，同业务反复沟通这个实时性的业务价值，后来发现大家更多的是因为一直以来的惯性在考虑数据的即时查询。（当然每个场景都有自己的判断。可能也未必适合：））