mysql数据库并发

A. mysql数据库超过并发量会pengding

mysql数据库超过并发量会pengding mysql数据库超过并发量会
主要是针对数据量很大，和并发访问量高的时候

经验一:

在开发过程中，我们经常会写

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 0,10

这样的语句用来分页

在有完美索引的情况 对xxx建立索引

前面几页会很快，但如果数据量达到100万级以后，我们查询最后一页

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

这句执行就会很慢，同时有多人访问服务器就会掉 (这里不考虑缓存，因为内容更新太快，有时候缓存了达不到数据的更新的要求)

但如果我们把

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

换成

SELECT * FROM table WHERE 1 ORDER BY xxx ASC LIMIT 0,10

这两个的MYSQL执行时间可是大大的不一样 当然要注意把这样取出来的结果用php重新排序一下

取得的一样是最后一页的数据，当然最中间的两页有部分数据一样

这时候最慢的只是最中间的部分，相对而言，访问最中间的人还是很少的

经验二:

例如论坛帖子列表的显示:

一般是SELECT * FROM table ORDER BY is_top DESC ,post_time DESC LIMIT 0,10这样的分页

两个order by 的执行是非常慢的，哪怕你有再好的索引，

我们的处理办法是 把is_top的数据CACHE住，毕竟is_top的数据量有限，更新这个缓存也容易

然后SQL一样是SELECT * FROM table ORDER BY post_time DESC LIMIT {$num},{$num2}

注意这个$num2 是减掉is_top的数量后的一个值,$num是is_top的数量

当然还要考虑is_top的数据量是不是有好几页,当前页的值是不是都在cache里面

经验三:

SELECT * FROM table ORDER BY RAND() LIMIT 100 这个ORDER BY RAND() 是非常慢的 能不用尽量不要用

处理办法是

1.用PHP生成数组后，然后用SELECT * FROM table WHERE id IN() WHERE IN 也比这个order by rand()快的多

2.如果数量信息不太重多，就用SELECT * FROM table WHERE 1 LIMIT 500 多取点数据，然后用php 处理数组

B. mysql锁能控制并发吗

可以的，mysql中典型的是mvcc协议：

MVCC是为了实现数据库的并发控制而设计的一种协议。从直观理解上来看，要实现数据库的并发访问控制，最简单的做法就是加锁访问，即读的时候不能写（允许多个西线程同时读，即共享锁，S锁），写的时候不能读（一次最多只能有一个线程对同一份数据进行写操作，即排它锁，X锁）。这样的加锁访问，其实并不算是真正的并发，或者说它只能实现并发的读，因为它最终实现的是读写串行化，这样就大大降低了数据库的读写性能。加锁访问其实就是和MVCC相对的LBCC，即基于锁的并发控制（Lock-Based Concurrent Control），是四种隔离级别中级别最高的Serialize隔离级别。为了提出比LBCC更优越的并发性能方法，MVCC便应运而生。

C. mysql并发数是什么意思

可能影响，并可能影响。这就是所谓的“一个老鼠屎坏了一锅汤。”许多DBA都遇到类似的问题，即一台服务器上，在服务器上的所有应用程序的应用程序编程问题，导致多个应用程序的数据都受到牵连。但是，根据你的描述，如果唯一的A1死锁，然后A2是不是一个问题。但是，如果的A1表扫描或复杂的计算，导致太多的资源，这将影响到A2的压力。

数据库的并发性通常指的是整个服务器的并发性，无论数据库服务器的几个库

D. 如何增加mysql数据库并发数

现象

Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

• MySQL error log 未见异常.

• syslog 未见异常.

• tcpmp 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.

• 自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响

猜想2

怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:

• 检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.

• 通过strace检查MySQL, 发现accept()调用确实没有感知到新连接.

怀疑是OS的原因, Google之, 得到参考文档:A TCP “stuck” connection mystery【http://www.evanjones.ca/tcp-stuck-connection-mystery.html】

分析

参考文档中的现象跟目前的状况很类似, 简述如下:

正常的TCP连接流程:

• Client 向 Server 发起连接请求, 发送SYN.

• Server 预留连接资源, 向 Client 回复SYN-ACK.

• Client 向 Server 回复ACK.

• Server 收到 ACK, 连接建立.

• 在业务层上, Client和Server间进行通讯.

当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:

• Client 向 Server 发起连接请求, 发送SYN.

• Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.

• Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).

• Server 验证签名, 分配连接资源, 连接建立.

• 在业务层上, Client和Server间进行通讯.

当启用SYN-cookie时, 第3步的ACK包因为某种原因丢失, 那么:

• 从Client的视角, 连接已经建立.

• 从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)

发生这种情况时:

• 若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误

• 若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.

TCP握手的第三步ACK包为什么丢失

参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:

• Some of these packets get lost because some buffer somewhere overflows.



我们可以通过Systemtap进一步探究原因.通过一个简单的脚本:

• probe kernel.function("cookie_v4_check").return
  

• {

• source_port = @cast($skb->head + $skb->transport_header, "struct tcphdr")->source

• printf("source=%d, return=%d ",readable_port(source_port), $return)

• }

• function readable_port(port) {

• return (port & ((1<<9)-1)) << 8 | (port >> 8)

• }

观察结果, 可以确认cookie_v4_check(syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.

之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):

• static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk->sk_ack_backlog > sk- >sk_max_ack_backlog;}



恢复故障与日志的正关联

在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.

当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.

检查linux源码:

• if (!queue->synflood_warned &&

• sysctl_tcp_syncookies != 2 &&

• xchg(&queue->synflood_warned, 1) == 0)

• pr_info("%s: Possible SYN flooding on port %d. %s.
  

• Check SNMP counters. ",

• proto, ntohs(tcp_hdr(skb)->dest), msg);

可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.

粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.

解决方案

这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.

解决方案:
1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
2. 关闭syn_cookie. 有安全的人又要跳出来了.
3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.

有多个系统参数混合影响syn backlog长度, 参看【http://blog.bbelboer.com/2012/04/09/syn-cookies.html】

下图为精华总结

E. 如何使用mysql数据库解决高并发

使用mysql异步查询,需要使用mysqlnd作为PHP的MySQL数据库驱动。 使用MySQL异步... 如果创建的线程过多,则会造成线程切换引起系统负载过高。Swoole中的异步MySQL其...

F. mysql数据库怎么解决高并发问题

通常情况下在PHP中MySQL查询是串行的，如果能实现MySQL查询的异步化，就能实现多条SQL语句同时执行，这样就能大大地缩短MySQL查询的耗时，提高数据库查询的效率。目前MySQL的异步查询只在MySQLi扩展提供，查询方法分别是：
1、使用MYSQLI_ASYNC模式执行mysqli::query
2、获取异步查询结果：mysqli::reap_async_query
使用mysql异步查询，需要使用mysqlnd作为PHP的MySQL数据库驱动。
使用MySQL异步查询，因为需要给所有查询都创建一个新的连接，而MySQL服务端会为每个连接创建一个单独的线程进行处理，如果创建的线程过多，则会造成线程切换引起系统负载过高。Swoole中的异步MySQL其原理是通过MYSQLI_ASYNC模式查询，然后获取mysql连接的socket，加入到epoll事件循环中，当数据库返回结果时会回调指定函数，这个过程是完全异步非阻塞的。

G. 如何处理mysql数据库并发更新问题

mysql的最大连接数默认是100, 这个数值对于并发连接很多的数据库应用是远远不够的，当连接请求大于默认连接数后，就会出现无法连接数据库的错误，因此我们需要把它适当调大一些。 调节方法为： 1.linux服务器中：改my中国f中的值就行了 2.Windows服务器中（我用的）:     在文件“my.ini”中找到段   [mysqld],在其中添加一行     max_connections=200         ###   200可以更改为想设置成的值.     然后重启"mysql"服务。 /mysqladmin所在路径/mysqladmin -uroot -p variables 输入root数据库账号的密码后可看到 | max_connections | 1000 |   其他需注意的：     在编程时，由于用mysql语句调用数据库时，在每次之执行语句前，会做一个临时的变量用来打开数据库，所以你在使用mysql语句的时候，记得在每次调用完mysql之后就关闭mysql临时变量。     另外对于访问量大的，可以考虑直接写到文本中，根据预测的访问量，先定义假若是100个文件文件名依次为1.txt,2.txt...100.txt。需要的时候，再对所有文本文件中的数据进行分析，再导入数据库