你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!
发表了文章 o 0 个评论 o 19 次浏览 o 20 小时前
o 来自相关话题
下面列举出来的一些小技巧在邮件管理员的日常中会经常用到，如果有什么错误，请留言交流。
打印邮件队列：
# postqueue –p
如果队列数较大可以配合tail查看：
# mailq | tail
刷新队列：
# postqueue -f
立即为队列中的域名的邮件发送：
# postqueue -
删除队列中所有邮件：
# postsuper -d ALL
删除一个特定的信息：
# postsuper -d messageid
重新发送特定的邮件:
# postfix -r msgid
查看postfix邮件版本：
# postconf -d mail_version
mail_version = 2.6.6
原文原文： /blog/postfix-configuration-and-explanation-of-parameters/
下面列举出来的一些小技巧在邮件管理员的日常中会经常用到，如果有什么错误，请留言交流。
打印邮件队列：
# postqueue –p
如果队列数较大可以配合tail查看：
# mailq | tail
刷新队列：
# postqueue -f
立即为队列中的域名的邮件发送：
# postqueue -
删除队列中所有邮件：
# postsuper -d ALL
删除一个特定的信息：
# postsuper -d messageid
重新发送特定的邮件:
# postfix -r msgid
查看postfix邮件版本：
# postconf -d mail_version
mail_version = 2.6.6
原文原文：
发表了文章 o 0 个评论 o 39 次浏览 o
o 来自相关话题
超融合基础架构，是一种将计算、网络、存储和安全等资源作为基本组成元素，根据系统需求进行选择和预定义的一种技术架构。
深信服紧密围绕客户价值需求，提出了超融合构建的企业级云方案，其在逻辑上分为两个层面：一层是云基础架构层面，通过超融合来实现，只用通用的x86服务器和二三层交换机，通过完全软件定义的方式实现云基础架构；另一层是云管平台，实现底层云基础架构和上层应用的紧密融合。
深信服致力于企业级云解决方案，并一直秉承着“利用创新云化技术，帮助客户打造极简、随需应变、平滑演进的IT新架构”的理念。深信服企业云方案兼具超融合和云管理的独特价值，是数据中心云化的最佳路径。
深信服企业级云，基础架构只有X86服务器和交换机两种设备，使得云数据中心的初始建设成本大幅下降，基于分布式架构，三台一体机就能构建资源池，系统可靠性得到有效保障，而基于模块化标准化的资源池，使建设过程变得非常简单。
云时代，超融合已成为当前云计算基础架构领域最大的热点，如何构建企业级云？最先进的超融合架构什么样？8月29日14:00“大话超融合——全融合云IT帮您轻松上云”直播活动即将开启，听听超融合领域资深专家为您指点迷津。
直播间地址：/home/live/live/liveid/10038.html
超融合基础架构，是一种将计算、网络、存储和安全等资源作为基本组成元素，根据系统需求进行选择和预定义的一种技术架构。
深信服紧密围绕客户价值需求，提出了超融合构建的企业级云方案，其在逻辑上分为两个层面：一层是云基础架构层面，通过超融合来实现，只用通用的x86服务器和二三层交换机，通过完全软件定义的方式实现云基础架构；另一层是云管平台，实现底层云基础架构和上层应用的紧密融合。
深信服致力于企业级云解决方案，并一直秉承着“利用创新云化技术，帮助客户打造极简、随需应变、平滑演进的IT新架构”的理念。深信服企业云方案兼具超融合和云管理的独特价值，是数据中心云化的最佳路径。
深信服企业级云，基础架构只有X86服务器和交换机两种设备，使得云数据中心的初始建设成本大幅下降，基于分布式架构，三台一体机就能构建资源池，系统可靠性得到有效保障，而基于模块化标准化的资源池，使建设过程变得非常简单。
云时代，超融合已成为当前云计算基础架构领域最大的热点，如何构建企业级云？最先进的超融合架构什么样？8月29日14:00“”直播活动即将开启，听听超融合领域资深专家为您指点迷津。
直播间地址：
回复了问题 o 3 人关注 o 3 个回复 o 5851 次浏览 o
o 来自相关话题
发表了文章 o 0 个评论 o 39 次浏览 o
o 来自相关话题
目前，云计算，大数据等概念已经深入人心。不过时至今日，云计算到底是什么，恐怕还是有很多人不知如何回答？那么，云计算又和网格计算、自主计算等有什么差异呢？本文将着重为您解析，云计算和网格计算的区别之处。
所谓云计算，在国际上的定义多达数百种，其中比较权威的应该是美国国家标准与技术研究员（NIST）的解释：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务器、存储、应用软件、服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。
简单的来说，所谓云计算就是利用在Internet中可用的计算系统，能够支持互联网各类应用的系统。云计算是以第三方拥有的机制提供服务，为了完成功能，用户只关心需要的服务。
网格计算，即分布式计算，是一门计算机科学，他主要的目的是如何把一个需要非常巨大的计算能力才能解决的问题拆分成若干部分，然后把这些部分分配给多台计算机进行处理，最后汇总所有的计算结果而得出最终结果。
云计算可以说是网格计算的衍生品，能够根据需要提供资源，一般情况下，云计算采用计算机集群构成数据中心，并以服务的形势提供给客户，让客户可以像使用水、电一样按需购买资源，从这个角度来看，云计算和网格计算的目标是非常相似的。
云计算和网格计算的不同点
云计算和网格计算都是可伸缩的。可伸缩性是通过独立运行在通过Web服务连接的各种操作系统上的应用程序实例的负载平衡实现的。CPU和网络带宽根据需要分配和回收。系统存储能力根据特定时间的用户数量、实例的数量和传输的数据量进行调整。
相对于强调异构资源共享的网格计算，云计算更强调大规模资源池的分享，通过分享提高资源复用率，并利用规模经济降低运行成本；而网格计算常用于集中大量资源来执行一些大型任务。
通常，网格计算关注的是计算量非常大的操作。网格计算要求软件的使用可以分为多个部分，将程序的片段作为大的系统映像传递给几千个计算机中。这其中系统软硬件成本以及运营的成本都非常高。而相比之下，云计算需要考虑经济成本，因此硬件设备、软件平台的设计不再一味追求高性能，而要综合考虑成本、可用性、可靠性等因素。
简言之，云计算是以相对集中的资源，运行分散的应用；而网格计算则是聚合分散的资源，支持大型集中式应用。
了解更多云计算知识请登录OTPUB领先IT学习直播平台：
目前，云计算，大数据等概念已经深入人心。不过时至今日，云计算到底是什么，恐怕还是有很多人不知如何回答？那么，云计算又和网格计算、自主计算等有什么差异呢？本文将着重为您解析，云计算和网格计算的区别之处。
所谓云计算，在国际上的定义多达数百种，其中比较权威的应该是美国国家标准与技术研究员（NIST）的解释：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务器、存储、应用软件、服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。
简单的来说，所谓云计算就是利用在Internet中可用的计算系统，能够支持互联网各类应用的系统。云计算是以第三方拥有的机制提供服务，为了完成功能，用户只关心需要的服务。
网格计算，即分布式计算，是一门计算机科学，他主要的目的是如何把一个需要非常巨大的计算能力才能解决的问题拆分成若干部分，然后把这些部分分配给多台计算机进行处理，最后汇总所有的计算结果而得出最终结果。
云计算可以说是网格计算的衍生品，能够根据需要提供资源，一般情况下，云计算采用计算机集群构成数据中心，并以服务的形势提供给客户，让客户可以像使用水、电一样按需购买资源，从这个角度来看，云计算和网格计算的目标是非常相似的。
云计算和网格计算的不同点
云计算和网格计算都是可伸缩的。可伸缩性是通过独立运行在通过Web服务连接的各种操作系统上的应用程序实例的负载平衡实现的。CPU和网络带宽根据需要分配和回收。系统存储能力根据特定时间的用户数量、实例的数量和传输的数据量进行调整。
相对于强调异构资源共享的网格计算，云计算更强调大规模资源池的分享，通过分享提高资源复用率，并利用规模经济降低运行成本；而网格计算常用于集中大量资源来执行一些大型任务。
通常，网格计算关注的是计算量非常大的操作。网格计算要求软件的使用可以分为多个部分，将程序的片段作为大的系统映像传递给几千个计算机中。这其中系统软硬件成本以及运营的成本都非常高。而相比之下，云计算需要考虑经济成本，因此硬件设备、软件平台的设计不再一味追求高性能，而要综合考虑成本、可用性、可靠性等因素。
简言之，云计算是以相对集中的资源，运行分散的应用；而网格计算则是聚合分散的资源，支持大型集中式应用。
了解更多云计算知识请登录OTPUB领先IT学习直播平台：
回复了问题 o 1 人关注 o 1 个回复 o 56 次浏览 o
o 来自相关话题
回复了问题 o 2 人关注 o 1 个回复 o 44 次浏览 o
o 来自相关话题
发表了文章 o 1 个评论 o 56 次浏览 o
o 来自相关话题
最近研发的项目对 DB 依赖比较重，梳理了这段时间使用MySQL遇到的8个比较具有代表性的问题，答案也比较偏自己的开发实践，没有 DBA专业和深入，有出入的请使劲拍砖！
一、MySQL读写性能是多少，有哪些性能相关的重要参数？
这里做了几个简单压测实验，结果如下：
机器：8核CPU，8G内存
表结构(尽量模拟业务)：12个字段(1个bigint(20)为自增primary key，5个int(11)，5个varchar(512)，1个timestamp)，InnoDB存储引擎。
实验1(写)：insert =& 6000/s
前提：连接数100，每次insert单条记录
分析：CPU跑了50%，这时磁盘为顺序写，故性能较高实验2(写)：update(where条件命中索引) =& 200/s
前提：连接数100，10w条记录，每次update单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑2%，瓶颈明显在IO的随机写实验3(读)：select(where条件命中索引) =& 5000/s
前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑6%，瓶颈在IO，和db的cache大小相关实验4(读)：select(where条件没命中索引) =& 60/s
前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑到80%，每次select都需遍历所有记录，看来索引的效果非常明显！几个重要的配置参数，可根据实际的机器和业务特点调整
max_connecttions：最大连接数
table_cache：缓存打开表的数量
key_buffer_size：索引缓存大小
query_cache_size：查询缓存大小
sort_buffer_size：排序缓存大小(会将排序完的数据缓存起来)
read_buffer_size：顺序读缓存大小
read_rnd_buffer_size：某种特定顺序读缓存大小(如order by子句的查询)PS：查看配置方法：show variables like '%max_connecttions%';
二、MySQL负载高时，如何找到是由哪些SQL引起的？
方法：慢查询日志分析(MySQLdumpslow)
慢查询日志例子，可看到每个慢查询SQL的耗时：
# User@Host: edu_online[edu_online] @
[10.139.10.167]
# Query_time: 1.958000
Lock_time: 0.000021 Rows_sent: 254786
Rows_examined: 254786
SET timestamp=;
select * from t_online_group_日志显示该查询用了1.958秒，返回254786行记录，一共遍历了254786行记录。及具体的时间戳和SQL语句。
使用MySQLdumpslow进行慢查询日志分析：
MySQLdumpslow -s t -t 5 slow_log_.txt输出查询耗时最多的Top5条SQL语句
-s：排序方法，t表示按时间 (此外，c为按次数，r为按返回记录数等)
-t：去Top多少条，-t 5表示取前5条
执行完分析结果如下：
Count: 1076100
Time=0.09s (99065s)
Lock=0.00s (76s)
Rows=408.9 (), edu_online[edu_online]@28hosts
select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & N
Count: 1076099
Time=0.05s (52340s)
Lock=0.00s (91s)
Rows=62.6 (), edu_online[edu_online]@28hosts
select * from t_online_course where UNIX_TIMESTAMP(c_updatetime) & N
Count: 63889
Time=0.78s (49607s)
Lock=0.00s (3s)
Rows=0.0 (18), edu_online[edu_online]@[10x.213.1xx.1xx]
select f_uin from t_online_student_contact where f_modify_time & N
Count: 1076097
Time=0.02s (16903s)
Lock=0.00s (72s)
Rows=52.2 (), edu_online[edu_online]@28hosts
select * from t_online_video_info where UNIX_TIMESTAMP(v_update_time) & N
Count: 330046
Time=0.02s (6822s)
Lock=0.00s (45s)
Rows=0.0 (2302), edu_online[edu_online]@4hosts
select uin,cid,is_canceled,unix_timestamp(end_time) as endtime,unix_timestamp(update_time) as updatetime
from t_kick_log where unix_timestamp(update_time) & N以第1条为例，表示这类SQL(N可以取很多值，这里MySQLdumpslow会归并起来)在8月19号的慢查询日志内出现了1076100次，总耗时99065秒，总返回行记录，有28个客户端IP用到。
通过慢查询日志分析，就可以找到最耗时的SQL，然后进行具体的SQL分析
慢查询相关的配置参数：
log_slow_queries：是否打开慢查询日志，得先确保=ON后面才有得分析
long_query_time：查询时间大于多少秒的SQL被当做是慢查询，一般设为1S
log_queries_not_using_indexes：是否将没有使用索引的记录写入慢查询日志
slow_query_log_file：慢查询日志存放路径
三、如何针对具体的SQL做优化？
使用Explain分析SQL语句执行计划
MySQL& explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & ;
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table
| type | possible_keys | key
| key_len | ref
| rows | Extra
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 | SIMPLE
| t_online_group_records | ALL
| NULL | NULL
47 | Using where |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)如上面例子所示，重点关注下type，rows和Extra：
type：使用类别，有无使用到索引。结果值从好到坏：... & range(使用到索引) & index & ALL(全表扫描)，一般查询应达到range级别
rows：SQL执行检查的记录数
Extra：SQL执行的附加信息，如&Using index&表示查询只用到索引列，不需要去读表等
使用Profiles分析SQL语句执行时间和消耗资源：
MySQL& set profiling=1; (启动profiles，默认是没开启的)
MySQL& select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & ; (执行要分析的SQL语句)
+----------+------------+----------------------------------------------------------------------------------------------+
| Query_ID | Duration
+----------+------------+----------------------------------------------------------------------------------------------+
1 | 0. | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) &
+----------+------------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MySQL& show profile cpu,block io for query 1; (可看出SQL在各个环节的耗时和资源消耗)
+----------------------+----------+----------+------------+--------------+---------------+
| Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| optimizing
| 0.000016 | 0.000000 |
0.000000 |
| statistics
| 0.000020 | 0.000000 |
0.000000 |
| preparing
| 0.000017 | 0.000000 |
0.000000 |
| executing
| 0.000011 | 0.000000 |
0.000000 |
| Sending data
| 0.000076 | 0.000000 |
0.000000 |
SQL优化的技巧 (只提一些业务常遇到的问题)
1、最关键：索引，避免全表扫描
对接触的项目进行慢查询分析，发现TOP10的基本都是忘了加索引或者索引使用不当，如索引字段上加函数导致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)&)
+----------+------------+---------------------------------------+
| Query_ID | Duration
+----------+------------+---------------------------------------+
1 | 0. | select * from mytable where id=100
2 | 0. | select * from mytable where id+1=101
+----------+------------+---------------------------------------+另外很多同学在拉取全表数据时，喜欢用select xx from xx limit 这种形式批量拉取，其实这个SQL每次都是全表扫描，建议添加1个自增id做索引，将SQL改为 select xx from xx where id&5000 and id&6000;
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration
+----------+------------+-----------------------------------------------------+
1 | 0. | select * from mytable where id&=90000 and id&=91000 |
2 | 0. | select * from mytable limit
+----------+------------+-----------------------------------------------------+合理用好索引，应该可解决大部分SQL问题。当然索引也非越多越好，过多的索引会影响写操作性能。
1.1 只select出需要的字段，避免select
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration
+----------+------------+-----------------------------------------------------+
1 | 0. | select count(1) from ( select id from mytable ) a
2 | 1. | select count(1) from ( select * from mytable ) a
+----------+------------+-----------------------------------------------------+1.2 尽量早做过滤，使Join或者Union等后续操作的数据量尽量小
1.3 把能在逻辑层算的提到逻辑层来处理，如一些数据排序、时间函数计算等
PS：关于SQL优化，已经有足够多文章了，所以就不讲太全面了，只重点说自己1个感受：索引！基本都是因为索引！
四、SQL层面已难以优化，请求量继续增大时的应对策略？
下面是我能想到的几个方法，每个方法又都是一篇大文章了，这里就不展开。
分库分表使用集群(master-slave)，读写分离增加业务的cache层使用连接池
五、MySQL如何做主从数据同步？
复制机制（Replication）
master通过复制机制，将master的写操作通过binlog传到slave生成中继日志(relaylog)，slave再将中继日志redo，使得主库和从库的数据保持同步。
复制相关的3个MySQL线程：
slave上的I/O线程：向master请求数据master上的Binlog Dump线程：读取binlog事件并把数据发送给slave的I/O线程slave上的SQL线程：读取中继日志并执行，更新数据库
属于slave主动请求拉取的模式
实际使用可能遇到的问题
数据非强一致：CDB默认为异步复制，master和slave的数据会有一定延迟(称为主从同步距离，一般 & 1s)
主从同步距离变大：可能是DB写入压力大，也可能是slave机器负载高，网络波动等原因，具体问题具体分析
相关监控命令
show processlist：查看MySQL进程信息，包括3个同步线程的当前状态
show master status ：查看master配置及当前复制信息
show slave status：查看slave配置及当前复制信息
六、如何防止DB误操作和做好容灾？
业务侧应做到的几点：
重要DB数据的手工修改操作，操作前需做到2点：1 先在测试环境操作 2 备份数据根据业务重要性做定时备份，考虑系统可承受的恢复时间进行容灾演练，感觉很必要
MySQL备份和恢复操作
1、备份：使用MySQLdump导出数据
MySQLdump -u 用户名 -p 数据库名 [表名] & 导出的文件名
MySQLdump -uxxx -p xxx mytable & mytable..bak.sql2、恢复：导入备份数据
MySQL -uxxx -p xxxx & mytable..bak.sql3、恢复：导入备份数据之后发送的写操作。先使用MySQLbinlog导出这部分写操作SQL(基于时间点或位置)
如导出 09:59:59之后的binlog：
MySQLbinlog --database=&test& --start-date=& 09:59:59& /var/lib/MySQL/mybinlog.000001 & binlog.data.sql如导出起始id为123456之后的binlog：
MySQLbinlog --database=&test& --start-position=&123456& /var/lib/MySQL/mybinlog.000001 & binlog.data.sql最后把要恢复的binlog导入db
MySQL -uxxxx -p xxxx & binlog.data.sql
七、该选择MySQL哪种存储引擎，Innodb具有什么特性？
存储引擎简介：
插件式存储引擎是MySQL的重要特性，MySQL支持多种存储引擎以满足用户的多种应用场景
存储引擎解决的问题：如何组织MySQL数据在介质中高效地读取，需考虑存储机制、索引设计、并发读写的锁机制等
MySQL5.0支持的存储引擎有MyISAM、InnoDB、Memory、Merge等
MyISAM和InnoDB的区别(只说重点了)
1. InnoDB，MySQL5.5之后及CDB的默认引擎
支持行锁：并发性能好支持事务：故InnoDB称为事务性存储引擎，支持ACID，提供了具有提交、回滚和崩溃恢复能力的事务安全支持外键：当前唯一支持外键的引擎
2. MyISAM，MySQL5.5之前默认引擎
支持表锁：插入+查询速度快，更新+删除速度慢不支持事务
使用show engines可查看当前MySQL支持的存储引擎详情：
八、MySQL内部结构有哪些层次？
非专业DBA，这里只简单贴个结构图说明下。MySQL是开源系统，其设计思路和源代码都出自大牛之手，有空可以学习下。
Connectors：连接器。接收不同语言的Client交互Management Serveices & Utilities：系统管理和控制工具Connection Pool: 连接池。管理用户连接SQL Interface: SQL接口。接受用户的SQL命令，并且返回用户需要查询的结果Parser: 解析器。验证和解析SQL语句成内部数据结构Optimizer: 查询优化器。为查询语句选择合适的执行路径Cache和Buffer：查询缓存。缓存查询的结果，有命中即可直接返回Engine：存储引擎。MySQL数据最后组织并存储成具体文件
作者：王昂
原文地址：/community/article/233
最近研发的项目对 DB 依赖比较重，梳理了这段时间使用MySQL遇到的8个比较具有代表性的问题，答案也比较偏自己的开发实践，没有 DBA专业和深入，有出入的请使劲拍砖！
一、MySQL读写性能是多少，有哪些性能相关的重要参数？
这里做了几个简单压测实验，结果如下：
机器：8核CPU，8G内存
表结构(尽量模拟业务)：12个字段(1个bigint(20)为自增primary key，5个int(11)，5个varchar(512)，1个timestamp)，InnoDB存储引擎。
实验1(写)：insert =& 6000/s
前提：连接数100，每次insert单条记录
分析：CPU跑了50%，这时磁盘为顺序写，故性能较高实验2(写)：update(where条件命中索引) =& 200/s
前提：连接数100，10w条记录，每次update单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑2%，瓶颈明显在IO的随机写实验3(读)：select(where条件命中索引) =& 5000/s
前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑6%，瓶颈在IO，和db的cache大小相关实验4(读)：select(where条件没命中索引) =& 60/s
前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))
分析：CPU跑到80%，每次select都需遍历所有记录，看来索引的效果非常明显！几个重要的配置参数，可根据实际的机器和业务特点调整
max_connecttions：最大连接数
table_cache：缓存打开表的数量
key_buffer_size：索引缓存大小
query_cache_size：查询缓存大小
sort_buffer_size：排序缓存大小(会将排序完的数据缓存起来)
read_buffer_size：顺序读缓存大小
read_rnd_buffer_size：某种特定顺序读缓存大小(如order by子句的查询)PS：查看配置方法：show variables like '%max_connecttions%';
二、MySQL负载高时，如何找到是由哪些SQL引起的？
方法：慢查询日志分析(MySQLdumpslow)
慢查询日志例子，可看到每个慢查询SQL的耗时：
# User@Host: edu_online[edu_online] @
[10.139.10.167]
# Query_time: 1.958000
Lock_time: 0.000021 Rows_sent: 254786
Rows_examined: 254786
SET timestamp=;
select * from t_online_group_日志显示该查询用了1.958秒，返回254786行记录，一共遍历了254786行记录。及具体的时间戳和SQL语句。
使用MySQLdumpslow进行慢查询日志分析：
MySQLdumpslow -s t -t 5 slow_log_.txt输出查询耗时最多的Top5条SQL语句
-s：排序方法，t表示按时间 (此外，c为按次数，r为按返回记录数等)
-t：去Top多少条，-t 5表示取前5条
执行完分析结果如下：
Count: 1076100
Time=0.09s (99065s)
Lock=0.00s (76s)
Rows=408.9 (), edu_online[edu_online]@28hosts
select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & N
Count: 1076099
Time=0.05s (52340s)
Lock=0.00s (91s)
Rows=62.6 (), edu_online[edu_online]@28hosts
select * from t_online_course where UNIX_TIMESTAMP(c_updatetime) & N
Count: 63889
Time=0.78s (49607s)
Lock=0.00s (3s)
Rows=0.0 (18), edu_online[edu_online]@[10x.213.1xx.1xx]
select f_uin from t_online_student_contact where f_modify_time & N
Count: 1076097
Time=0.02s (16903s)
Lock=0.00s (72s)
Rows=52.2 (), edu_online[edu_online]@28hosts
select * from t_online_video_info where UNIX_TIMESTAMP(v_update_time) & N
Count: 330046
Time=0.02s (6822s)
Lock=0.00s (45s)
Rows=0.0 (2302), edu_online[edu_online]@4hosts
select uin,cid,is_canceled,unix_timestamp(end_time) as endtime,unix_timestamp(update_time) as updatetime
from t_kick_log where unix_timestamp(update_time) & N以第1条为例，表示这类SQL(N可以取很多值，这里MySQLdumpslow会归并起来)在8月19号的慢查询日志内出现了1076100次，总耗时99065秒，总返回行记录，有28个客户端IP用到。
通过慢查询日志分析，就可以找到最耗时的SQL，然后进行具体的SQL分析
慢查询相关的配置参数：
log_slow_queries：是否打开慢查询日志，得先确保=ON后面才有得分析
long_query_time：查询时间大于多少秒的SQL被当做是慢查询，一般设为1S
log_queries_not_using_indexes：是否将没有使用索引的记录写入慢查询日志
slow_query_log_file：慢查询日志存放路径
三、如何针对具体的SQL做优化？
使用Explain分析SQL语句执行计划
MySQL& explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & ;
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table
| type | possible_keys | key
| key_len | ref
| rows | Extra
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 | SIMPLE
| t_online_group_records | ALL
| NULL | NULL
47 | Using where |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)如上面例子所示，重点关注下type，rows和Extra：
type：使用类别，有无使用到索引。结果值从好到坏：... & range(使用到索引) & index & ALL(全表扫描)，一般查询应达到range级别
rows：SQL执行检查的记录数
Extra：SQL执行的附加信息，如&Using index&表示查询只用到索引列，不需要去读表等
使用Profiles分析SQL语句执行时间和消耗资源：
MySQL& set profiling=1; (启动profiles，默认是没开启的)
MySQL& select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) & ; (执行要分析的SQL语句)
+----------+------------+----------------------------------------------------------------------------------------------+
| Query_ID | Duration
+----------+------------+----------------------------------------------------------------------------------------------+
1 | 0. | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) &
+----------+------------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MySQL& show profile cpu,block io for query 1; (可看出SQL在各个环节的耗时和资源消耗)
+----------------------+----------+----------+------------+--------------+---------------+
| Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
| optimizing
| 0.000016 | 0.000000 |
0.000000 |
| statistics
| 0.000020 | 0.000000 |
0.000000 |
| preparing
| 0.000017 | 0.000000 |
0.000000 |
| executing
| 0.000011 | 0.000000 |
0.000000 |
| Sending data
| 0.000076 | 0.000000 |
0.000000 |
SQL优化的技巧 (只提一些业务常遇到的问题)
1、最关键：索引，避免全表扫描
对接触的项目进行慢查询分析，发现TOP10的基本都是忘了加索引或者索引使用不当，如索引字段上加函数导致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)&)
+----------+------------+---------------------------------------+
| Query_ID | Duration
+----------+------------+---------------------------------------+
1 | 0. | select * from mytable where id=100
2 | 0. | select * from mytable where id+1=101
+----------+------------+---------------------------------------+另外很多同学在拉取全表数据时，喜欢用select xx from xx limit 这种形式批量拉取，其实这个SQL每次都是全表扫描，建议添加1个自增id做索引，将SQL改为 select xx from xx where id&5000 and id&6000;
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration
+----------+------------+-----------------------------------------------------+
1 | 0. | select * from mytable where id&=90000 and id&=91000 |
2 | 0. | select * from mytable limit
+----------+------------+-----------------------------------------------------+合理用好索引，应该可解决大部分SQL问题。当然索引也非越多越好，过多的索引会影响写操作性能。
1.1 只select出需要的字段，避免select
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration
+----------+------------+-----------------------------------------------------+
1 | 0. | select count(1) from ( select id from mytable ) a
2 | 1. | select count(1) from ( select * from mytable ) a
+----------+------------+-----------------------------------------------------+1.2 尽量早做过滤，使Join或者Union等后续操作的数据量尽量小
1.3 把能在逻辑层算的提到逻辑层来处理，如一些数据排序、时间函数计算等
PS：关于SQL优化，已经有足够多文章了，所以就不讲太全面了，只重点说自己1个感受：索引！基本都是因为索引！
四、SQL层面已难以优化，请求量继续增大时的应对策略？
下面是我能想到的几个方法，每个方法又都是一篇大文章了，这里就不展开。
分库分表使用集群(master-slave)，读写分离增加业务的cache层使用连接池
五、MySQL如何做主从数据同步？
复制机制（Replication）
master通过复制机制，将master的写操作通过binlog传到slave生成中继日志(relaylog)，slave再将中继日志redo，使得主库和从库的数据保持同步。
复制相关的3个MySQL线程：
slave上的I/O线程：向master请求数据master上的Binlog Dump线程：读取binlog事件并把数据发送给slave的I/O线程slave上的SQL线程：读取中继日志并执行，更新数据库
属于slave主动请求拉取的模式
实际使用可能遇到的问题
数据非强一致：CDB默认为异步复制，master和slave的数据会有一定延迟(称为主从同步距离，一般 & 1s)
主从同步距离变大：可能是DB写入压力大，也可能是slave机器负载高，网络波动等原因，具体问题具体分析
相关监控命令
show processlist：查看MySQL进程信息，包括3个同步线程的当前状态
show master status ：查看master配置及当前复制信息
show slave status：查看slave配置及当前复制信息
六、如何防止DB误操作和做好容灾？
业务侧应做到的几点：
重要DB数据的手工修改操作，操作前需做到2点：1 先在测试环境操作 2 备份数据根据业务重要性做定时备份，考虑系统可承受的恢复时间进行容灾演练，感觉很必要
MySQL备份和恢复操作
1、备份：使用MySQLdump导出数据
MySQLdump -u 用户名 -p 数据库名 [表名] & 导出的文件名
MySQLdump -uxxx -p xxx mytable & mytable..bak.sql2、恢复：导入备份数据
MySQL -uxxx -p xxxx & mytable..bak.sql3、恢复：导入备份数据之后发送的写操作。先使用MySQLbinlog导出这部分写操作SQL(基于时间点或位置)
如导出 09:59:59之后的binlog：
MySQLbinlog --database=&test& --start-date=& 09:59:59& /var/lib/MySQL/mybinlog.000001 & binlog.data.sql如导出起始id为123456之后的binlog：
MySQLbinlog --database=&test& --start-position=&123456& /var/lib/MySQL/mybinlog.000001 & binlog.data.sql最后把要恢复的binlog导入db
MySQL -uxxxx -p xxxx & binlog.data.sql
七、该选择MySQL哪种存储引擎，Innodb具有什么特性？
存储引擎简介：
插件式存储引擎是MySQL的重要特性，MySQL支持多种存储引擎以满足用户的多种应用场景
存储引擎解决的问题：如何组织MySQL数据在介质中高效地读取，需考虑存储机制、索引设计、并发读写的锁机制等
MySQL5.0支持的存储引擎有MyISAM、InnoDB、Memory、Merge等
MyISAM和InnoDB的区别(只说重点了)
1. InnoDB，MySQL5.5之后及CDB的默认引擎
支持行锁：并发性能好支持事务：故InnoDB称为事务性存储引擎，支持ACID，提供了具有提交、回滚和崩溃恢复能力的事务安全支持外键：当前唯一支持外键的引擎
2. MyISAM，MySQL5.5之前默认引擎
支持表锁：插入+查询速度快，更新+删除速度慢不支持事务
使用show engines可查看当前MySQL支持的存储引擎详情：
八、MySQL内部结构有哪些层次？
非专业DBA，这里只简单贴个结构图说明下。MySQL是开源系统，其设计思路和源代码都出自大牛之手，有空可以学习下。
Connectors：连接器。接收不同语言的Client交互Management Serveices & Utilities：系统管理和控制工具Connection Pool: 连接池。管理用户连接SQL Interface: SQL接口。接受用户的SQL命令，并且返回用户需要查询的结果Parser: 解析器。验证和解析SQL语句成内部数据结构Optimizer: 查询优化器。为查询语句选择合适的执行路径Cache和Buffer：查询缓存。缓存查询的结果，有命中即可直接返回Engine：存储引擎。MySQL数据最后组织并存储成具体文件
作者：王昂
原文地址：
发表了文章 o 0 个评论 o 45 次浏览 o
o 来自相关话题
随着应用BI系统的广泛应用，数据治理的话题也越来越受到企业的关注和讨论，有专家表示，如果想让用户进入真正的商业智能时代，就必须建立一定的数据治理体系；而大数据治理能够在短期内成为业内的焦点，这和企业对大数据质量的理解和密切关注有很大关系。
大数据治理面临的挑战：规模庞大，标准不一
过去几年，企业的IT系统经历了数据量高速膨胀的一个时期，这些海量的，分散在不同服务器的数据提高了数据资源利用的复杂性和管理难度；另外，各个企业内部的业务区分和行政区分也对企业数据的交互造成了一定的断层，而企业与外部业务交互所产生的“体外循环”数据与企业的核心数据体系并不能自然地融合。当这种数据的异构化所导致的应用冲突达到一定临界点时，数据治理便成为了规范企业数据的必要步骤。
大数据治理技术：主题众多，元数据管理先行
数据治理涉及的IT技术主题众多，包括元数据管理、主数据管理、数据质量、数据集成、监控与报告等。在很多国际企业中，元数据管理的重要性在全部技术主题中位列第一。
元数据管理是语义工具，其重要性在于，它能够为数据治理建立一套数据资料库，存储治理范围内的数据定义，负责人，来源，转换关系，目标，质量等级，依赖关系，安全权限等。这些信息对于商业整合，数据质量，可审计性等数据治理目标的实现至关重要。
元数据管理是实施数据治理的核心IT技术，有效的元数据管理将为数据质量、数据集成等技术的实施，以及数据治理目标的最终实现奠定坚实的基础。
大数据治理的意义：发掘数据资产的商业价值
大数据治理是为了将数据作为企业商业资产进行应用和管理的一套数据管理机制，能够通过建立规范的数据应用标准，消除数据的不一致性，来提高数据的质量，并能合理的将数据应用于企业的业务管理和战略决策中，充分的发挥数据的商业价值，良好的数据治理必将为信息化时代的企业带来不可替代的竞争优势。
了解更多大数据相关知识请进入OTPUB官网：
随着应用BI系统的广泛应用，数据治理的话题也越来越受到企业的关注和讨论，有专家表示，如果想让用户进入真正的商业智能时代，就必须建立一定的数据治理体系；而治理能够在短期内成为业内的焦点，这和企业对大数据质量的理解和密切关注有很大关系。
大数据治理面临的挑战：规模庞大，标准不一
过去几年，企业的IT系统经历了数据量高速膨胀的一个时期，这些海量的，分散在不同服务器的数据提高了数据资源利用的复杂性和管理难度；另外，各个企业内部的业务区分和行政区分也对企业数据的交互造成了一定的断层，而企业与外部业务交互所产生的“体外循环”数据与企业的核心数据体系并不能自然地融合。当这种数据的异构化所导致的应用冲突达到一定临界点时，数据治理便成为了规范企业数据的必要步骤。
大数据治理技术：主题众多，元数据管理先行
数据治理涉及的IT技术主题众多，包括元数据管理、主数据管理、数据质量、数据集成、监控与报告等。在很多国际企业中，元数据管理的重要性在全部技术主题中位列第一。
元数据管理是语义工具，其重要性在于，它能够为数据治理建立一套数据资料库，存储治理范围内的数据定义，负责人，来源，转换关系，目标，质量等级，依赖关系，安全权限等。这些信息对于商业整合，数据质量，可审计性等数据治理目标的实现至关重要。
元数据管理是实施数据治理的核心IT技术，有效的元数据管理将为数据质量、数据集成等技术的实施，以及数据治理目标的最终实现奠定坚实的基础。
大数据治理的意义：发掘数据资产的商业价值
大数据治理是为了将数据作为企业商业资产进行应用和管理的一套数据管理机制，能够通过建立规范的数据应用标准，消除数据的不一致性，来提高数据的质量，并能合理的将数据应用于企业的业务管理和战略决策中，充分的发挥数据的商业价值，良好的数据治理必将为信息化时代的企业带来不可替代的竞争优势。
了解更多大数据相关知识请进入OTPUB官网：
发表了文章 o 0 个评论 o 55 次浏览 o
o 来自相关话题
公司名：深圳某智能计算科技有限公司
职位：SDN开发工程师
薪资：20K-30K/月
岗位职责：
1、承担SDN交换机软件开发(基于DPDK和OVS开发)，性能优化。
2、负责软件代码编写，能够独立完成软件模块的编码、测试等工作。参与技术攻关，协助解决各种编程难题。
3、负责软件开发文档编写，配合测试人员完成系统测试及改进工作。
4、参与市场开局的技术支持。
任职要求：
1、具有全日制本科及以上学历。
2、计算机、通信、信息系统等相关专业。
3、三年以上前后端软件开发经验，熟练掌握C/C++，Java等前后端编程语言。
4、熟悉或者了解二、三层路由交换原理，TCP/IP协议，有数通产品开发经验优先。
5、精通 SDN相关技术:Openflow协议，Openvswitch的原理和实现，DPDK技术原理。
有意思者可以加我微信：
公司名：深圳某智能计算科技有限公司
职位：SDN开发工程师
薪资：20K-30K/月
岗位职责：
1、承担SDN交换机软件开发(基于DPDK和OVS开发)，性能优化。
2、负责软件代码编写，能够独立完成软件模块的编码、测试等工作。参与技术攻关，协助解决各种编程难题。
3、负责软件开发文档编写，配合测试人员完成系统测试及改进工作。
4、参与市场开局的技术支持。
任职要求：
1、具有全日制本科及以上学历。
2、计算机、通信、信息系统等相关专业。
3、三年以上前后端软件开发经验，熟练掌握C/C++，Java等前后端编程语言。
4、熟悉或者了解二、三层路由交换原理，TCP/IP协议，有数通产品开发经验优先。
5、精通 SDN相关技术:Openflow协议，Openvswitch的原理和实现，DPDK技术原理。
有意思者可以加我微信：
回复了问题 o 2 人关注 o 1 个回复 o 80 次浏览 o
o 来自相关话题
3 个问题, 1 人关注
0 个问题, 0 次赞同
0 个问题, 0 次赞同
33 个问题, 32 次赞同
专业的互联网开放交流社区.
为互联网工作者提供乐点.
开源中国社区&