Net分层架构中，数据访问的主要职责是
数据访问层：有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。 简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。
SQL数据库如何优化
面试的时候经常会文档一些SQL方面的问题，比较常见的面试题例如“什么时候回造成索引失效？”，又或者“你经常做的SQL优化的工作有哪些？”
下面，我就介绍几个有关SQL优化的知识点。
负向条件查询不能使用索引：包括!=、not in、not exists都尽量不要使用；
%在前面的模糊查询：where name like '%xxx'；
等号左边有函数：where upper(str) = '...'，就算str字段有索引，这个写法也不会走索引；
数据区分度不大的字段，不要建索引：例如性别男、女、为止，这种就不适合建立索引；
隐式转换：where tel = 13800000000，如果tel字段是varchar类型，这个写法不会报错，但是会索引失效；
只返回需要的数据：select name，gender from users 优于 select * from users；
允许为Null的列，有风险：比如 where name != 'Tom'，如果name允许为Null，索引不储存Null值，结果集不包含这些记录；因为索引不存储Null值，所以is null也不会走索引；
如果业务大部分是单条记录查询，那么Hash索引效率更高
复合索引最左前缀：（name,gender）复合索引，where name=xx and gender =x 可以命中，where name=xx可以命中，where gender =x不能命中。
我会持续分享Java程序开发、架构设计、职业发展等方面的知识和见解，希望能得到你的关注今日头条，转载请注明出处。
之前在BAT里参与过一个公司级应用（非市场级，投入的人力也不会那么大），上线2年后，总是被用户投诉，原因是这个应用使用MySql数据库来做持久层，但是2年了，有一张非常重要的存储历史任务的表实在是太大了，导致通过页面想要查询历史数据的速度变得非常非常慢，所以用户很是不满意。
分析下来，这不是用Redis能解决的缓存问题，而是历史数据的查询响应速度问题。
我们最开始是希望能够通过增加索引的方式解决，但是面对千万级别的数据量，我们也不敢贸然加索引，因为一旦数据库hang住，期间的所有数据库写入请求都会被放到等待队列中，如果请求是通过http请求发过来的，很有可能导致服务发生分钟级别的超时不响应。
虽然经常被用户投诉反应慢，也不能破罐破摔，直接超时不响应了吧。
于是我们陷入了两难的境地。
后来我们分了两个部分来优化持久层。
MySQL的主从>设置/strong>
第一步就是配置MySQL的主从库，通过将读写请求分离，来提高数据库的响应速度。
从上图可知，来自同一台服务器的请求，经过MySQL-proxy被分流给了不同的MySQL节点，其中写请求给了主节点，读请求给了从节点。因此，我们首先通过分流的方式，减轻了单节点MySQL的响应压力，实现了优化的第一步。
引入ElasticSearch
但是，只配置MySQL的主从是远远不够的。
通过查阅论坛，相关资料，我们最终敲定在持久层引入ElasticSearch。
Elastic Search是一个轻量级的持久层工具，它支持动态多节点部署，自动备份，节点掉线后能够自动切换主从，动态广播发现新上线的节点，而这些优点的应用，无须修改任何server端配置。可以这样理解，如果你部署了4个elastic search节点，其中2个掉了，服务器还是可以很好的继续运行。
此外，它还有一个最重要的优势，那就是支持大数据快速查询。一张几千万的表，如果用MySQL查询，可能需要几秒到几十秒不等，但是如果用elastic search，只需要毫秒级别就能查询到结果。完美的解决了我们当前的问题，还顺带帮我们巩固了持久层的稳定性问题。
综上，优化Mysql的目的是为持久层服务，除了引入主从配置，当MySQL自身局限性导致无法继续优化后，引入其他技术也是十分必要的。
如果你对这篇回答有任何问题，欢迎在下方点赞，留言。
我是苏苏思量，来自BAT的java开发工程师，头像是本人，每天都会分享科技类见闻，欢迎关注我，与我共同进步。
