十二、网站访问慢数据库问题及数据库核心管理思想

一.网站访问慢案例套路

      网站访问慢，可能有多种情况，这里主要是mysql数据库慢引起的排除情况。

     1.show  full processlist;进行查看，通常查询结果是空，如果执行两遍，结果都是一样的，那么基本就能确定是这条语句了。

       2.在my.cnf中，

         long_query_time=1
        log-slow-queries= /data/3306/show.log   

      也是可以进行查看的，查看到底是哪个语句进行了慢查询。

    、

      3.查看当前的负载情况：uptime，  大致负载就是服务器的核数，分别表示  1分钟、5分钟、15分钟的负载，正常情况下，一般都是0.00，表示很空闲

       [root@proxy ~]# uptime
       19:53:30 up 1 day,  3:53,  3 users,  load average: 0.00, 0.00, 0.00
 
     4.对于查询出来的语句，要排查是否走了索引，查看索引情况：
        explain  sql语句  ---查看sql是否走了索引
        select SQL_NO_CACHE sql语句  --不走缓存的查询sql语句

  

      5.查看sql语句对应的所需要查询的所有列的行数，确定索引的建立
         例如：select count(distinct ader) from ad_odlboy_detail;

          这里需要注意：一般条件是=的索引效果最高
         创建联合索引：
            create index  d_a_p  on  ad_olboy_detail(dateline,ader(20),pos(20));

 

       6.再次测试，查看show full processlist,uptime 等，基本mysql数据库问题解决。

 

二、如果查询结果中有%%时，比如百度一个：脑白金，那么在后台mysql数据库中的语句是：select xx like ‘%脑白金%’

    一般在数据库进行了阻塞后，整体网站打开是非常慢的，但是因为%%的原因，无法通过索引进行处理，这里给出4中方案： 

       1）从业务上解决，让用户登陆上再进行搜索，减少一部分用户的搜索情况

       2）频繁搜索，一般是爬虫在爬，分析web日志IP封杀
       3）配置主从同步，读写分离

       4）在数据库前端加memcached缓存

     短期情况  1）2）方案进行处理 ；后期情况发展为3）4）方案进行处理。

 

三、mysql数据库安全权限控制管理思想

   1.项目制度与流程管理

   办公室开发--办公司测试--IDC测试环境--IDC正式环境。通过这种较为完善的项目开发制度及流程控制，尽可能的防止潜在的问题隐患发生。

    2.数据库更新流程

    开发人员提交需求--开发主管--部门领导审核--DBA审核--DBA执行项目--IDC正式执行

注意：

  1)   数据库流程执行完毕后，再项目制度与流程管理上进行执行操作完毕

  2）开发在提交需要后，要告知领导和审核人员，然后依次审核，对于紧急需求，可以根据紧急程度特殊处理，可以制定紧急需求处理流程

  3）通过这种完善的流程控制，可以防止很多潜在的数据丢失、破坏等问题的发生。（重要的思想是控制发生，并不是发生了解决的能力）

 

 四、一次服务器CPU占用率高的定位分析 推荐（地址：https://www.cnblogs.com/gaoyuechen/p/8595258.html）

 

背景：通过性能监控发现上线服务器cpu某核占用率已经达到了100%，而且是由我们的某个核心服务导致的。幸亏由于我们的服务进程由多个相同worker（线程）调度承担的，所以除了CPU占用率高之外，并没有对服务造成影响。随着上次我们找到那个吃IO的罪犯，这次我们要追捕的是潜伏在团体中的特务，更加惊险刺激哟！

---

系统环境

用top命令很容易定位到是谁占用CPU最高。

以我们的这个业务进程（imDevServer）举例，为什么说这货是个潜伏者呢？因为这是个多线程的进程，我们要知道实际上占用cpu的最小单位是线程，所以肯定是众线程中的某一个或几个占用CPU过高导致的。top -H -p pid命令查看进程内各个线程占用的CPU百分比

如上图所示我们可以看出id为8863的线程cpu占用率最高。好，我们现在只要能找到他偷走的cpu就好了，虽然这小子嘴巴严，但是我们有一套完善的审问流程，不怕他不招。首先出马的是strace -T -r -c -p pid命令

它的作用是查看系统调用和花费的时间，epoll_wait虽然占用的调用时间多，但是他本身是个正常的阻塞调用。

我们接着让pstack pid出马

可以看到每个线程的调用堆栈，找到已经找出的占用CPU最高的那个线程，然后看他的调用堆栈，很容易看出在哪一步逻辑上导致了busy loop，

再使用trace -p tid看看线程的调用过程接着定位到代码，修复bug，找回被偷走的cpu。

推荐：linux trace命令详解 https://blog.csdn.net/chtnj/article/details/79072549