写这篇文章的出发点是记录我在工作中处理数据的问题中累计的经验，写着写着发现每一个点都会衍生出其它的背景知识，如优化索引时需要对慢查询、Explain等相关功能有一定的了解，如引入Elasticsearch需要解决数据的同步，学习Elasticsearch的知识等等，由于文章的篇幅不可能把每一个点都像视频教程一样细细道来，只能以我有限的认知和对一些通用性的点进行归纳总结。即便是这样，文章的篇幅也已经很长了，大家如果对某一点有兴趣的话还请自行baidu/google单个细节的深入知识。
文章的篇幅较长，如有兴趣不妨品味一遍，希望没有浪费您的数十分钟。【推荐学习：《mysql视频教程》】
数据库技术到目前共经历了人工管理阶段、文件系统阶段和数据库系统阶段。
在早期没有软件系统的时候，通过手工计帐和口头协议的人工管理阶段也能实现现实世界对某种业务运行，这种形式存在了相当长的时间，是效率相对低下的一种方案。往后的一个阶段，随着计算机技术的发展，出现了以excel表格代替手工计帐的文件系统阶段，一定程度的提高了生产力。再到软件系统以操作简单、效率高效的数据库系统阶段，实现了生产力的再次提升，把现实世界的具体问题抽象成了数据，通过数据的流转与变动来表代现实世界的业务。而在软件系统中，数据的存储一般由一个关系型数据库搭配多个非关系型数据库组建而成。
数据库跟系统业务是强关联的，这就要求产品经理的设计业务的时候要了解数据存储跟查询的流程，在设计之初就明确改业务对数据库会有什么影响跟是否需要引用新的技术栈。如产品经理设计的一个业务是对多张单表体积百万级的mysql表进行数据统计分析汇总，如果直接用mysql多表查询的话一定会产生慢查询从而导致msyql服务的宕机，这时解决方案便是要不产品端妥协，要不改变技术栈。
系统架构与数据库方案中要选择更合适公司团队能力的，在系统前期，简单的数据库优化配合钞能力会是最有性价比方案，但遇到mysql数据库钞能力也无能为力的时候，引入对关键功能为核心的软件服务就会成为最有性价比方案，如何在遇到问题时选择合适的方案，就是体现你价值的时候了。
一个穷小伙攀上一个富家女，短暂的甜蜜終敌不过现实阶级的不对等，美好的结局只存在于穷小伙的幻想与琼瑶老师的电视剧中。
如何在有限的成本中提升数据存储的性能，便是本文章于大家论讨的中心思想。
相信大家的日常工作中会经常接触到以下内容，小弟就简单地总结一下吧。
关系型数据库就是由二维表及其之间的联系所组成的一个数据组织,为软件提供事务数据一致性、数据持久化等功能，是软件系统的核心存储服务，是我们开发跟面试都是最常接触到的数据库，对于一些小型外包项目，一个mysql足以满足全部的业务需求了。就是一个我们经常接触到的东西，内里其实是充满了门道的，往后章节再细聊其中门道。
优点：
问题
MySQL数据库作为一种关系型数据的存储软件，有优点同时也有明显的缺点，因此通常在软件系统数据量不断扩大与业务复杂度不段提升的情况下，不能指望通过增强MySQL数据库的能力来解决全部的问题，用是引入其他存储软件，利用各类型的NoSql来解决软件系统数据量不断扩大与业务复杂度不段提升的问题。
关系型数据库是对关系型数据库的在不同场景的优化，不是意味着引入某种NoSql就万事大吉，而是充分了解市面上NoSQL的类型与应用难度，在合适的场景下选择合适的存储软件才是正确的做法。
在业务中会存在经常对某些表的内容进行查询，但查询的结果绝大数是不变的，所以出现了以Memcached、Redis为主的Key-value存储软件，广泛应用在系统中的缓存模块。Redis比Memcached多多的数据结构与持久化让其成为KV型NoSql中应用最广的。
全文搜索的场景下，MySQLB+树索引的查询优化，like查询是无法命中索引的，每一次like关键字查询都是一次全表扫描，在几万条数据量的表还算可以支撑，但数据最一在就会产生慢查询，要是业务代码写得不好在事务中调用了Like查询就会产生读锁。以倒排索引为核心的ElasticSearch为能完美地满足全文搜索的场景，同时ElasticSearch对海量数据支持也十分好，文档与生态也很好，ElasticSearch是搜索型的代表产品。
文档型NoSql指的是将半结构化数据存储为文档的一种NoSql，文档型NoSql通常以JSON或者XML格式存储数据，因此文档型NoSql是没有Schema的，由于没有Schema的特性，我们可以随意地存储与读取数据，因此文档型NoSql的出现是解决关系型数据库表结构扩展不方便的问题的。笔者没有使用过
对于一定规模的企业，业务上会经常涉及到一些实时且灵活的数据汇总，这种业务不太合适用提前计算的方案来解决，那怕是能用提前计算汇总的方案写出了业务，但随着汇总的数量据增加的时候，对汇总数据做最后一步累加也会慢慢变得很慢，那列式NoSql就是这种场景下的产物，大数据时代最具代表性的技术之一了，常见的有HBase，但HBase的应用是十分重的，往往需要一整套Hadoop生态来运行，笔者公司用的是阿里云的AnalyticDB，一个兼容MySql查询语句的列式存储软件。利用汇总+列式存储软件的强大查询能力，足以支持各种实时且灵活的数据汇总务业。
以2021年为时间节点来看，大多数的系统的初期都是以以下方案为起点的，接下来我会在这个案例中慢慢做一些调整。
硬件升级所带来的收益是越往后越收益越低，在时间、人员紧张的时候这是最快的优化方案。软件优化所带来的收益是越往后越收益越高，但越往后所要求技术人员的水平也越高，在时间、人员允许的情况下是最有性价比的优化方案。硬件与软件的优化不是互斥的，在需要的时候两者同时可接近MYSQL性能的上限。
阶段一
阶段二
阶段三
OLTP主要用来记录某类业务事件的发生，如用户行为，当行为产生后，系统会记录是用户在何时何地做了何事，这样的一行（或多行）数据会以增删改的方式在数据库中进行数据的更新处理操作，要求实时性高、稳定性强、确保数据及时更新成功，像常见的业务系统系统都属于OLTP，而使用的数据库都为带事务的数据库，如MySlq、Oracle等。对OLTP来说，提升查询的速度、服务稳定就是优化的核心
store_id_guide_id (store_id,guide_id) USING BTREEstore_id_guide_id (store_id,guide_id) USING BTREE
锁
按照粒度分，MySQL锁可以分为全局锁、表级锁、行锁
全局锁
表级锁分为表锁（数据锁）和元数据锁
行锁会锁住数据行，分为共享锁和独占锁
解决死锁
show processlist;SELECT * FROM information_schema.INNODB_TRX; //长事务SELECT * FROM information_schema.INNODB_LOCKs; //查看锁SELECT * FROM information_schema.INNODB_LOCK_waits; //查看阻塞事务
Elasticsearch的倒排索引，适合做全文搜索，但数据构结的灵活性差。
OLAP是相对于OLTP事务处理场景而然用来对数据的决策分析，是一种运用在大数据分析上的离线数仓思路，不是具体的技术栈,当你的方案能体现OLAP分析处理的思路的话，那该方案就是OLAP了。
早期数据仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站log，IoT设备数据，APP埋点数据等，这些数据量比以往结构化的数据大了几个量级。
无论OLAP面对的业务如何变化，都离不开以下的步骤：确定分析领域->同步业务数据到运算库->数据清洗建模->同步到数据仓库->对外暴露
其中计算源数据库是为专门给数据清洗用的，目的是避免数据清洗时影响业务数据库的性能。通过将计算源数据库的数据按业务、维度清洗，增加数据易用性和复用性，得到最终的实时明细数据，落盘到数据仓库，再由数据仓库提供最后的决策分析数据。
DEMO方案
生产方案
每个环节的软件都是可用相同功能的软件替换的，用团队最有把握的软件实现方案，那该方案就是OLAP了。
优化要遵循脚踏实地，一步步地做能力沉淀，多轮迭代，不可一蹴而就。基于自己的基础、业务场景和未来的发展预期来多轮迭代。
迭代的原则是先把单个软件服务通过软优化与硬优化提升软件的效率，当优化成本低于收益时，站在未来的发展预期参考市面上成熟的方案，跟据方案按需地引入新的软件进行组合式创新，切忌盲目照搬，有机地融合才能达到1+1>2、2+1>3的效果，当引用的软件遇到瓶颈时再反复这个过程。
谢谢您看到这里，以上便是文章的所有内容，内容中所提出的优化点与方案不一定是最优解，是个人工作中的最佳实践，有不同见解欢迎谈论交流。
以上是高赞分享：符合生产的MySQL优化思路的详细内容。更多信息请关注PHP中文网其他相关文章！
