mssql，mysql，sqlserver三者有何不同

mssql就是SqlServer。全称是：Microsoft  SQL Server；是微软旗下的产品。

所以就是mysql和SqlServer的区别了。

sqlserver

优点：

易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等；

为数据管理与分析带来了灵活性，允许单位在快速变化的环境中从容响应，从而获得竞争优势。从数据管理和分析角度看，将原始数据转化为商业智能和充分利用Web带来的机会非常重要。

作为一个完备的数据库和数据分析包，SQLServer为快速开发新一代企业级商业应用程序、为企业赢得核心竞争优势打开了胜利之门。

作为重要的基准测试可伸缩性和速度奖的记录保持者，SQLServer是一个具备完全Web支持的数据库产品，提供了对可扩展标记语言 (XML)的核心支持以及在Internet上和防火墙外进行查询的能力；

缺点：

开放性 ：SQL Server 只能windows上运行没有丝毫开放性 *** 作系统系统稳定对数据库十分重要Windows9X系列产品偏重于桌面应用NT server只适合小型企业而且windows平台靠性安全性和伸缩性非常有限象unix样久经考验尤其处理大数据库；

伸缩性并行性 ：SQL server 并行实施和共存模型并成熟难处理日益增多用户数和数据卷伸缩性有限；

安全性：没有获得任何安全证书。

性能 ：SQL Server 多用户时性能佳 ；

客户端支持及应用模式： 客户端支持及应用模式。只支持C/S模式，SQL Server C/S结构只支持windows客户用ADO、DAO、OLEDB、ODBC连接；

使用风险：SQL server 完全重写代码经历了长期测试断延迟许多功能需要时间来证明并十分兼容；

MySql

优点：

体积小、速度快、总体拥有成本低，开源；

支持多种 *** 作系统；

是开源数据库，提供的接口支持多种语言连接 *** 作

MySql的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的MySql能很容易充分利用CPU；

MySql有一个非常灵活而且安全的权限和口令系统。当客户与MySql服务器连接时，他们之间所有的口令传送被加密，而且MySql支持主机认证；

支持ODBC for Windows， 支持所有的ODBC 2.5函数和其他许多函数， 可以用Access连接MySql服务器， 使得应用被扩展；

支持大型的数据库， 可以方便地支持上千万条记录的数据库。作为一个开放源代码的数据库，可以针对不同的应用进行相应的修改。

拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性；

MySQL同时提供高度多样性，能够提供很多不同的使用者介面，包括命令行客户端 *** 作，网页浏览器，以及各式各样的程序语言介面，例如C+，Perl，Java，PHP，以及Python。

可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上；

缺点：

不支持热备份；

MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变；

没有一种存储过程(Stored Procedure)语言，这是对习惯于企业级数据库的程序员的最大限制；

MySQL的价格随平台和安装方式变化。Linux的MySQL如果由用户自己或系统管理员而不是第三方安装则是免费的，第三方案则必须付许可费。Unix或Linux 自行安装 免费 、Unix或Linux 第三方安装收费。

MySQL里面为了提高客户端请求创建连接过程的性能,提供了一个连接池也就是

Thread_Cache池,将空闲的连接线程放在连接池中,而不是立即销毁.这样的好处就是,当又有一个新的请求的时候,mysql不会立即去创建连接

线程,而是先去Thread_Cache中去查找空闲的连接线程,如果存在则直接使用,不存在才创建新的连接线程.

有关Thread_Cache在MySQL有几个重要的参数,简单介绍如下:

thread_cache_size

Thread_Cache

中存放的最大连接线程数.在短连接的应用中Thread_Cache的功效非常明显,因为在应用中数据库的连接和创建是非常频繁的,如果不使用

Thread_Cache那么消耗的资源是非常可观的!在长连接中虽然带来的改善没有短连接的那么明显,但是好处是显而易见的.但并不是越大越好大了反而

浪费资源这个的确定一般认为和物理内存有一定关系,如下:

复制代码 代码如下:

1G —>8

2G —>16

3G —>32

>3G —>64

如果短连接多的话可以适当加大.

thread_stack

每个连接被创建的时候,mysql分配给它的内存.这个值一般认为默认就可以应用于大部分场景了,除非必要非则不要动它.

thread_handing

运用Thread_Cache处理连接的方式,5.1.19添加的新特性.有两个值可选[no-threads|one-thread-per-

connection] 看字面意思大家也该猜出八九分了,呵呵,no-threads

服务器使用一个线程,one-thread-per-connection

服务器为每个客户端请求使用一个线程.原手册中提到,no-threads是在Linux下调试用的.

复制代码 代码如下:

mysql>show variables like 'thread%'

+——————-+—————————+

| Variable_name | Value |

+——————-+—————————+

| thread_cache_size | 32|

| thread_handling | one-thread-per-connection |

| thread_stack | 196608|

+——————-+—————————+

3 rows in set (0.01 sec)

mysql>show status like '%connections%'

+———————-+——–+

| Variable_name| Value |

+———————-+——–+

| Connections | 199156 |

| Max_used_connections | 31 |

+———————-+——–+

2 rows in set (0.00 sec)

mysql>show status like '%thread%'

+————————+——–+

| Variable_name | Value |

+————————+——–+

| Delayed_insert_threads | 0 |

| Slow_launch_threads| 0 |

| Threads_cached | 3 |

| Threads_connected | 6 |

| Threads_created| 8689 |

| Threads_running| 5 |

+————————+——–+

6 rows in set (0.00 sec)

通过以上3个命令,可以看到服务器的 thread_cache池中最多可以存放32个连接线程,为每个客户端球使用一个线程.为每个连接的线程分配192k的内存空间.

服 务器总共有199156次连接,最大并发连接数为31,当前在thread_cashe池中的连接数为3个,连接数为6个,处于活跃状态的有5个,共创建 了8689次连接.显然这里以短连接为主.可以算出thread_cache命中率,公式为:

复制代码 代码如下:

Thread_Cache_Hit=(Connections-Thread_created)/Connections*100%

当前服务器的Thread_cache命中率约为95.6%这个结果我还是比较满意的.但是可以看出 thread_cache_size有点多余改成16或8更合理一些.

作者 王文安，腾讯CSIG数据库专项的数据库工程师，主要负责腾讯云数据库 MySQL 的相关的工作，热爱技术，欢迎留言进行交流。文章首发于腾讯云+社区的腾讯云数据库专家服务专栏。

在日常工作中，发现 MySQL 的状态不太对劲的时候，一般都会看看监控指标，很多时候会看到熟悉的一幕：CPU 使用率又爆了。本文将给大家介绍 MySQL 和 CPU 之间的关系，对此有一定的了解之后可以更准确的判断出问题的原因，也能够提前发现一些引发 CPU 问题的隐患。

怎么看懂CPU使用率

以 Linux 的 top 命令为例，效果如下：

Top 命令

在 %CPU 这一列就展示了 CPU 的使用情况，百分比指代的是总体上占用的时间百分比：

%us：表示用户进程的 CPU 使用时间(没有通过 nice 调度)

%sy：表示系统进程的 CPU 使用时间，主要是内核使用。

%ni：表示用户进程中，通过 CPU 调度(nice)过的使用时间。

%id：空闲的 CPU 时间

%wa：CPU 运行时在等待 IO 的时间

%hi：CPU 处理硬中断花费的时间

%si：CPU 处理软中断花费的时间

%st：被虚拟机偷走的 CPU 时间

通常情况下，我们讨论的 CPU 使用率过高，指的是 %us 这个指标，监控里面的 CPU 使用率通常也是这个值(也有用其他的方法计算出来的，不过简单起见，不考虑其他的情况 )。其他几个指标过高也代表出 MySQL 的状态异常，简单起见，这里主要还是指 %us 过高的场景。

MySQL和线程

MySQL 是单进程多线程的结构，意味着独占的 MySQL 服务器里面，只能用 top 命令看到一行数据。

TOP 命令效果

这里能看到的是 MySQL 的进程 ID，如果要看到线程的情况，需要用top -H

TOP 命令效果

在这里能看到的是 MySQL 各个线程的 ID，可以看到 MySQL 在启动之后，会创建非常多的内部线程来工作。

这些内部线程包括 MySQL 自己用来刷脏，读写数据等 *** 作的系统线程，也包括处理用户 SQL 的线程，姑且叫做用户线程吧。用户线程有一个特殊的地方：程序端发送到 MySQL 端的 SQL，只会由一个用户线程来执行(one-thread-per-connection)，所以 MySQL 在处理复杂查询的时候，会出现“一核有难，多核围观”的尴尬现象。

参考 %us 的定义，对于 Linux 系统来说，MySQL 进程和它启动的所有线程都不算内核进程，因此 MySQL 的系统线程和用户线程在繁忙的时候，都会体现在 CPU 使用率的 %us 指标上。

什么时候CPU会100%

MySQL 干什么的时候，CPU 会 100%？从前文的分析来看，MySQL 主要是两类线程占用 CPU：系统线程和用户线程。因此 MySQL 独占的服务器上，只需要留意一下这两类线程的情况，就能 Cover 住绝大部分的问题场景。

系统线程

在实际的环境中，系统线程遇到问题的情况会比较少，一般来说，多个系统线程很少会同时跑满，只要服务器的可用核心数大于等于 4 的话，一般也不会遇到 CPU 100%，当然有一些 bug 可能会有影响，比如这个：

MySQL BUG

虽然情况比较少，但是在面对问题的常规排查过程中，系统线程的问题也是需要关注的。

用户线程

提到用户线程繁忙，很多时候肯定会第一时间凭经验想到慢查询。确实 90% 以上的时候都是“慢查询”引起的，不过作为方法论，还是要根据分析再去得出结论的~

参考 us% 的定义，是指用户线程占用 CPU 的时间多少，这代表着用户线程占用了大量的时间。

一方面是在进行长时间的计算，例如：order by，group by，临时表，join 等。这一类问题可能是查询效率不高，导致单个 SQL 语句长时间占用 CPU 时间，也有可能是单纯的数据量比较多，导致计算量巨大。另一方面是单纯的 QPS 压力高，所以 CPU 的时间被用满了，比如 4 核的服务器用来支撑 20k 到 30k 的点查询，每个 SQL 占用的 CPU 时间并不多，但是因为整体的 QPS 很高，所以 CPU 的时间被占满了。

问题的定位

分析完之后，就要开始实战了，这里根据前文的分析给出一些经典的 CPU 100% 场景，并给出简要的定位方法作为参考。

PS：系统线程的 bug 的场景 skip，以后有机会再作为详细的案例来分析。

慢查询

在 CPU 100% 这个问题已经发生之后，真实的慢查询和因为 CPU 100% 导致被影响的普通查询会混在一起，难以直观的看 processlist 或者 slowlog 来发现尊敬的大船，这时候就需要一些比较明确的特征来进行甄别。

从前文的简单分析可以看出来，查询效率不高的慢查询通常有以下几种情况：

全表扫描：Handler_read_rnd_next 这个值会大幅度突增，且这一类查询在 slowlog 中 row_examined 的值也会非常高。

索引效率不高，索引选错了：Handler_read_next 这个值会大幅度的突增，不过要注意这种情况也有可能是业务量突增引起的，需要结合 QPS/TPS 一起看。这一类查询在 slowlog 中找起来会比较麻烦，row_examined 的值一般在故障前后会有比较明显的不同，或者是不合理的偏高。

比如数据倾斜的场景，一个小范围的 range 查询在某个特定的范围内 row_examined 非常高，而其他的范围时 row_examined 比较低，那么就可能是这个索引效率不高。

排序比较多：order by，group by 这一类查询通常不太好从 Handler 的指标直接判断，如果没有索引或者索引不好，导致排序 *** 作没有消除的话，那么在 processlist 和 slowlog 通常能看到这一类查询语句出现的比较多。

当然，不想详细的分析 MySQL 指标或者是情况比较紧急的话，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做个简单的除法，比如 row_examined/rows_sent >1000 的都可以拿出来作为“嫌疑人”处理。这类问题一般在索引方面做好优化就能解决。

PS：1000 只是个经验值，具体要根据实际业务情况来定。

计算量大

这一类问题通常是因为数据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼，反而是 slowlog 里面可能找不到，因为没有执行完的语句是不会记录的。

这一类问题一般来说有三种比较常规的解决方案：

读写分离，把这一类查询放到平时业务不怎么用的只读从库去。

在程序段拆分 SQL，把单个大查询拆分成多个小查询。

使用 HBASE，Spark 等 OLAP 的方案来支持。

高 QPS

这一类问题单纯的就是硬件资源的瓶颈，不论是 row_examined/rows_sent 的比值，还是 SQL 的索引、执行计划，或者是 SQL 的计算量都不会有什么明显问题，只是 QPS 指标会比较高，而且 processlist 里面可能什么内容都看不到，例如：

processlist

总结

实际上 CPU 100% 的问题其实不仅仅是单纯的 %us，还会有 %io，%sys 等，这些会涉及到 MySQL 与 Linux 相关联的一部分内容，展开来就会比较多了。本文仅从 %us 出发尝试梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的问题时，也可以用类似的思路，从这些指标的意义开始，结合 MySQL 的一些特性或者特点，逐步理清楚表象背后的原因。

---