上周末有感于一个网友留言，我写了篇短文，谈的是有些时候写东西得用点春秋笔法。可能有些朋友会觉得话说一半不如不说。比如说他们正在做数据库选型，希望了解某些数据库的优缺点，因此希望看到一些特别犀利的观点。

事实上，犀利的观点有些时候对于数据库选型或者国产数据库产业发展也并不一定有益。对于数据库选型而言，如果因为一个可能不够公正的犀利观点，或者说一个和你的应用场景关系不大的犀利观点而错过了一款十分适合你的数据库产品，那是很亏的事情。我一直认为数据库选型是十分个性化的事情，每个企业的判别标准都不同，某个数据库的缺陷或者优势不足以成为数据库选型的重要理由，参考网络上的文章去按图索骥难免陷入盲人摸象的困境。

比较理智的做法是通过技术比对，测试验证等方式，通过综合 评价，找到比较适合你的数据库产品，了解它，掌握它，并容忍它的不足。对于数据库的不足，通过部署架构优化、配置优化、数据架构适配、应用适配等手段尽可能优化它。

如果走另外一个极端，那么就是应用不做任何修改，必须让数据库来适配应用，这需要数据库产品十分完美，目前阶段，连Oracle都不敢说不需要做SQL优化就能跑得很好。目前的情况下，要想实现这一点是不容易的。目前金融行业的四大行以及一些比较有钱的股份制银行在数据库国产化替代的进度上还是挺快的，不过其他行业的情况就不是很乐观了。

前阵子一个国产化替代十分积极的央企在对其最核心的业务相同做适配测试的时候遇到了困难-所有参测数据库厂商均未能够通过测试。这是十分典型的我不去就山，必须让山来就我的案例，我有些质疑这次测试的科学性。

可能我使用Oracle比较早，我也感受过数据库替换的痛苦。因为VAX/VMS系统过于封闭，三十年前很多用户想把应用迁移到开放平台UNIX上，数据库也从DEC/RDB换成Oracle。当时我以为都是成熟的大型商用数据库，这个迁移会是很顺利的，没想到迁移后系统性能不达标。后来经过高手指点发现，原来Oracle这货不支持CBO优化器，所有的SQL都要检查修改，表连接的顺序错了，数据量稍大就会出性能问题。

当年我在Oracle上遇到的问题 ，和现在大家在国产数据库上遇到的问题可能很类似。因为将系统迁移到开放平台上是大势所趋，所以当时我们也只能咬咬牙去接受比较烂的Oracle，并且努力去用好它了。没想到对Oracle的这个宽容态度，让我未来的二十年有了一个稳定的饭碗。

我的这个经历分享给大家，是想给目前正在对国产数据库咬牙切齿的朋友一个建议。如果你真的热爱Oracle，讨厌国产数据库，那么你就要更加刻苦地提升Oracle的技术，在将来这个缩水了的市场中站稳你的脚跟，否则的话，我还是建议你抛弃你的执念，换一种角度去看国产数据库，为你未来的DBA生涯打下点基础。

我在我的公众号中谈国产数据库的问题，主要还是和数据库厂商和用户交流一下我的感受和观点，目的还是为了让国产数据库的技术水平尽快提升上去，改善用户的使用体验。如果你不是必须用国产数据库，那么你无需吐槽国产数据库的不堪，当然善意的指出问题，提出优化改进的建议下，那是多多益善的。如果你必须使用国产数据库，那么你和国产数据库厂商是友商关系，国产数据库再不堪也必须认真去拥抱它。不幸的婚姻，要么接受它的不幸，要么就努力改善它。最怕的就是絮絮叨叨的碎碎念，不仅无助于改善现状，只会让一切变得更糟。婚姻都如此，更何况没那么头疼的国产数据库了。

因为这些年在从事国产数据库相关生态工作，我和泰保的林春总经常在各种会议活动中相遇，也有幸经常在一起交流。听他谈国产数据库的使用体会是常常能学到东西的，因为这些年他一直在一个业务复杂度极高的行业内从事国产数据库替代的工作。他经常遇到坑，但是他的态度是努力把坑填了。他一直把国产数据库厂商当成自己的合作伙伴，虽然有时候这个伙伴也不大靠谱，但是几年来大家相濡以沫，把这项工作持续推进下去了 。随着时间的推移，数据库产品也在他们这样的用户的支持下越做越好，他们对国产数据库的信心也越来越足。

山不来就我，我便去就山。在数据库国产化替代已经是大势所趋的时候，多谈要不要替，能不能替已经没有什么意义了。通过自己的努力，为数据库国产化替代做些事情，同时通过参与这项工作，为自己积累未来职场的资本，应该是更好的选择 。