13.2 mysql索引优化生产案例（即12.网站访问慢数据库问题案例及数据库核心管理思想）

================================
18.网站打开慢排查基本思想
口头表达面试题
[root@oldboyedu-01 ~]# mysql -uroot -poldboy123 -S /data/3306/mysql.sock
查看进程列表：
mysql> show processlist;
[root@oldboyedu-01 ~]# uptime
17:22:01 up 23:22, 2 users, load average: 0.00, 0.00, 0.00
达到cpu核数负载就高了！系统性能的综合指标，超过CPU核数系统就比较慢，是个参考。
mysql> show variables like '%pro%';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| have_profiling | YES |
| profiling | OFF |
　　

================================
19.网站打开慢由于数据库慢导致 之数据库优化企业案例
a.数据库负载高，有慢查询，做联合索引案例。
优化起因：
法一：网站出问题，很慢。
mysql> show full processlist;
mysql> show full processlist;
说明某个数据没读完导致线程一直待着...
法二：开启慢查询语句（日志文件）
long_query_time=1
log-slow-queries=/data/3306/slow.log

案例举例：
[root@oldboyedu-01 ~]# uptime //比如很高
17:34:43 up 23:35, 2 users, load average: 0.00, 0.00, 0.00
[root@oldboyedu-01 ~]# mysql -uroot -poldboy123 -S /data/3306/mysql.sock
查看进程列表：
mysql> show processlist;
用户访问网站比较慢，我们确认了待优化select的语句，利用explain查看利用索引的情况：...
查看条件字段列的唯一性：...

根据以上和咨询研发经理使用语句较多的情况下，创建索引：...
提示：生产环境中如果访问频繁的大表，创建索引会很耗费时间，也许需要几分钟，应该在业务流量低谷时建立索引。

建立索引之后查看mysql线程，几乎看不到了，说明效果明显。
mysql> show full processlist;
mysql> show full processlist;
[root@oldboyedu-01 ~]# uptime

================================
20.网站打开慢由于数据库慢导致 之Memcached服务应用优化案例
b.数据库负载高，有慢查询，诸如LIKE'%杜冷丁%'，没法做索引案例。
案例举例：公司网站打开慢，数据库负载很高。
[root@oldboyedu-01 ~]# uptime //比如很高
17:34:43 up 23:35, 2 users, load average: 0.00, 0.00, 0.00
mysql> show full processlist;

[root@oldboyedu-01 ~]# mysql -uroot -poldboy123 -S /data/3306/mysql.sock -e "show full processlist"|grep -vi sleep
Id User Host db Command Time State Info
3 rep 10.0.0.200:41352 NULL Binlog Dump 5166 Master has sent all binlog to slave; waiting for binlog to be updated NULL
7 root localhost NULL Query 0 NULL show full processlist
说明：数据库中像 LIKE ‘%杜冷丁%’这样的语句特别多，导致数据库负载很高，该种语句对于mysql数据库没有太大优化余地。经判断打开网站首页应该是首页的搜索框搜索带来的结果。
优化思路：
（1）从业务上实现用户后登陆后再搜索，这样减少搜索次数，从而减轻数据库服务的压力。
（2）如果有大量频繁的搜索，一般是由爬虫在爬你的网站，分析web日志IP封掉之(awstats)。
（3）配置多个主从同步，程序上实现读写分离（最好让LIKE'%杜冷丁%'这样的查询去从库查），减轻主库读写压力。从库也可作集群！
（4）在数据库前端加上memcached缓存服务器。
（5）‘%杜冷丁%’这样的语句一般在mysql很难优化，可以通过搜索服务Sphinx实现搜索。
（6）当然还可以利用c,ruby开发程序，实现每日读库计算搜索索引，保存在服务器上提供搜索，然后每5分钟多一个从库做一次增量。这是大公司针对站内搜索采取的比较好的方法。
短期来看，倾向1,2方案，简单可实施；3,4是后期要发展的目标。
结果前端有人爬站，封掉IP就好了。

自己积累案例：
一主多从，主从库分别宕机的解决案例。
增量恢复案例，误操作导致数据破坏案例。

================================
22.安全优化-项目开发流程及数据库更新流程

================================
23.DBA参与项目数据库设计及培训开发人员高效设计mysql库语句

================================
24.项目周期的制定思想
注意：DBA参与项目数据库设计
在项目开发环节上，DBA或资深运维人员最好参与数据库设计与审核工作，这样可以从源头上减少降低不良的数据库设计及不良SQL语句的发生，还可以做所有语句的审核工作，包括select，但这个需要评估工作量是否允许，一般互联网公司实施全审核比较困难。

各种操作申请流程：
a.开发人员权限申请流程；
b.数据库更新执行流程；
c.烂的SQL语句计入KPI考核。

运维就是一场没有硝烟的战争
http://blog.51cto.com/oldboy/1296694

================================
25.linux进程占用cpu高的解决方案案例
[root@oldboyedu-01 ~]# top^C
[root@oldboyedu-01 ~]# strace
程序写了死循环了...

linux下 java/http进程高，占用cpu高的解决方案案例
https://www.cnblogs.com/Jimmy104/p/5254710.html

================================
26.数据库账户权限控制多种思路及技巧

================================
27.数据库客户端安全控制策略详解

================================
28.数据库运维的核心管理思想
（1）未雨绸缪，不要停留在制度上，而是实际做出来的。
（2）亡羊补牢，举一反三，切记，不能好了伤疤忘了疼。
（3）完备的架构设计及备份，恢复策略。
（4）定期思考，并实战模拟以上策略演练。

说明：其他的内容略。