×

mysql能抗住多少tps

mysql能抗住多少tps(mysql+tps+一般为多少)

admin admin 发表于2022-09-05 00:05:21 浏览363 评论0

抢沙发发表评论

本文目录

mysql+tps+一般为多少


(1)QPS(每秒Query量) QPS = Questions(or Queries) / seconds mysql 》 show global status like ’Question%’; (2)TPS(每秒事务量) TPS = (Com_commit + Com_rollback) / seconds mysql 》 show global status like ’Com_commit’; mysql 》 show global status like ’Com_rollback’; (3)key Buffer 命中率 mysql》show global status like ’key%’; key_buffer_read_hits = (1-key_reads / key_read_requests) * 100% key_buffer_write_hits = (1-key_writes / key_write_requests) * 100% (4)InnoDB Buffer命中率 mysql》 show status like ’innodb_buffer_pool_read%’; innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100% (5)Query Cache命中率

mysql数据库最大能支持多少并发量


MySQL服务器的最大并发连接数是16384。

受服务器配置,及网络环境等制约,实际服务器支持的并发连接数会小一些。主要决定因素有:

1、服务器CPU及内存的配置。

2、网络的带宽。互联网连接中上行带宽的影响尤为明显。

扩展资料:

优化数据库结构:

组织数据库的schema、表和字段以降低I/O的开销,将相关项保存在一起,并提前规划,以便随着数据量的增长,性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化,表的主键应尽可能短。·对于InnoDB表,主键所在的列在每个辅助索引条目中都是可复制的,因此如果有很多辅助索引,那么一个短的主键可以节省大量空间。

仅创建需要改进查询性能的索引。索引有助于检索,但是会增加插入和更新操作的执行时间。

InnoDB的ChangeBuffering特性:

InnoDB提供了changebuffering的配置,可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表操作和大量的I/O,以保证辅助索引保持最新。当相关页面不在缓冲池里面时,InnoDB的changebuffer将会更改缓存到辅助索引条目。-mysql能抗住多少tps

从而避免因不能立即从磁盘读取页面而导致耗时的I/O操作。当页面被加载到缓冲池时,缓冲的更改将被合并,更新的页面之后会刷新到磁盘。这样做可提高性能,适用于MySQL5.5及更高版本。

参考资料来源:百度百科-MySQL数据库



mysql 连接数 设置 多少合适


MySQL服务器的连接数并不是要达到最大的100%为好,还是要具体问题具体分析,下面就对MySQL服务器最大连接数的合理设置进行了详尽的分析,供您参考。
我们经常会遇见“MySQL: ERROR 1040: Too many connections”的情况,通常,mysql的最大连接数默认是100, 最大可以达到16384。
一种是访问量确实很高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力,另外一种情况是MySQL配置文件中max_connections值过小:
mysql》 show variables like ’max_connections’;
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 256 |
+-----------------+-------+
这台MySQL服务器最大连接数是256,然后查询一下服务器响应的最大连接数:
mysql》 show global status like ’Max_used_connections’;
MySQL服务器过去的最大连接数是245,没有达到服务器连接数上限256,应该没有出现1040错误,比较理想的设置是:
Max_used_connections / max_connections * 100% ≈ 85%
最大连接数占上限连接数的85%左右,如果发现比例在10%以下,MySQL服务器连接上线就设置得过高了
在Windows下常用的有两种方式修改最大连接数。
第一种:命令行修改。
》mysql -uuser -ppassword(命令行登录MySQL)
mysql》show variables like ’max_connections’;(查可以看当前的最大连接数)
msyql》set global max_connections=1000;(设置最大连接数为1000,可以再次查看是否设置成功)
mysql》exit(推出)
这种方式有个问题,就是设置的最大连接数只在mysql当前服务进程有效,一旦mysql重启,又会恢复到初始状态。因为mysql启动后的初始化工作是从其配置文件中读取数据的,而这种方式没有对其配置文件做更改。
第二种:修改配置文件。
这 种方式说来很简单,只要修改MySQL配置文件my.ini 或 my.cnf的参数max_connections,将其改为max_connections=1000,然后重启MySQL即可。但是有一点最难的就是my.ini这个文件在哪找。通常有两种可能,一个是在安装目录下(这是比较理想的情况),另一种是在数据文件的目录下,安装的时候如果没有人为改变目录的话,一般就在C:/ProgramData/MySQL往下的目录下。
与连接数相关的几个参数:
在修改最大连接数的时候会有这样一个疑问—这个值是不是越大越好,或者设置为多大才合适?这个参数的大小要综合很多因素来考虑,比如使用的平台所支持的线程库数量(windows只能支持到2048)、服务器的配置(特别是内存大小)、每个连接占用资源(内存和负载)的多少、系统需要的响应时间等。可以在global或session范围内修改这个参数。连接数的增加会带来很多连锁反应,需要在实际中避免由此引发的负面影响。
首先看一下MySQL的状态:
mysql》 status;
--------------
mysql Ver 14.14 Distrib 5.5.15, for Win32 (x86)
Connection id: 1
Current database:
Current user: root@localhost
SSL: Not in use
Using delimiter: ;
Server version: 5.5.15 MySQL Community Server (GPL)
Protocol version: 10
Connection: localhost via TCP/IP
Server characterset: utf8
Db characterset: utf8
Client characterset: gbk
Conn. characterset: gbk
TCP port: 3306
Uptime: 1 hour 3 min 27 sec
Threads: 12 Questions: 18 Slow queries: 10 Opens: 33 Flush tables: 5 Open tab
les: 34 Queries per second avg: 6.256
--------------
Open tables:34,即当前数据库打开表的数量是34个,注意这个34并不是实际的34个表,因为MySQL是多线程的系统,几个不同的并发连接可能打开同一个表,这就需要为不同的连接session分配独立的内存空间来存储这些信息以避免冲突。因此连接数的增加会导致MySQL需要的文件描述符数目的增加。另外对于MyISAM表,还会建立一个共享的索引文件描述符。
在MySQL数据库层面,有几个系统参数决定了可同时打开的表的数量和要使用的文件描述符,那就是table_open_cache、max_tmp_tables和open_files_limit。
mysql》 show variables like ’table_open%’;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| table_open_cache | 256 |
+------------------+-------+
1 row in set (0.00 sec)
table_open_cache:256,这就是说所有的MySQL线程一共能同时打开256个表,我们可以搜集系统的打开表的数量的历史记录和这个参数来对比,决定是否要增加这个参数的大小。查看当前的打开表的数目(Open tables)可用上边提到过的status命令,另外可以直接查询这个系统变量的值:
mysql》 show status like ’open_tables’;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 3 |
+---------------+-------+
1 row in set (0.00 sec)
Open_tables就是当前打开表的数目,通过flush tables命令可以关闭当前打开的表。 这个值如果过大,并且如果没有经常的执行flush tables命令,可以考虑增加table_open_cache参数的大小。

接下来看max_tmp_tables:
mysql》 show variables like ’max_tmp%’;
+----------------+-------+
| Variable_name | Value |
+----------------+-------+
| max_tmp_tables | 32 |
+----------------+-------+
1 row in set (0.00 sec)
max_tmp_tables:32即单个客户端连接能打开的临时表数目。查看当前已打开的临时表的信息:
mysql》 show global status like ’%tmp%table%’;
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 11 |
+-------------------------+-------+
2 rows in set (0.00 sec)
根据这两个值可以判断临时表的创建位置,一般选取BLOB和TEXT列、Group by 和 Distinct语句的数据量超过512 bytes,或者union的时候select某列的数据超过512 bytes的时候,就直接在磁盘上创建临时表了,另外内存中的临时表变大的时候,也可能被MySQL自动转移到磁盘上(由tmp_table_size和max_heap_table_size参数决定)。

增加table_open_cache或max_tmp_tables 参数的大小后,从操作系统的角度看,mysqld进程需要使用的文件描述符的个数就要相应的增加,这个是由open_files_limit参数控制的。
mysql》 show variables like ’open_files%’;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 2670 |
+------------------+-------+
1 row in set (0.00 sec)
但是这个参数是OS限制的,所以我们设定的值并不一定总是生效。如果OS限制MySQL不能修改这个值,那么置为0。如果是专用的MySQL服务器上,这个值一般要设置的尽量大,就是设为没有报Too many open files错误的最大值,这样就能一劳永逸了。当操作系统无法分配足够的文件描述符的时候,mysqld进程会在错误日志里记录警告信息。
相应的,有两个状态变量记录了当前和历史的文件打开信息:
mysql》 show global status like ’%open%file%’;
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 0 |
| Opened_files | 76 |
+---------------+-------+
2 rows in set (0.00 sec)
MySQL为每个连接分配线程来处理,可以通过threads_connected参数查看当前分配的线程数量:
mysql》 show status like ’%thread%’;
+------------------------------------------+-------+
| Variable_name | Value |
+------------------------------------------+-------+
| Delayed_insert_threads | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Slow_launch_threads | 0 |
| Threads_cached | 0 |
| Threads_connected | 1 |
| Threads_created | 1 |
| Threads_running | 1 |
+------------------------------------------+-------+
8 rows in set (0.00 sec)
比较threads_connected参数和前面提到的max_connections参数,也可以作为目前的系统负载的参照,决定是否需要修改连接数。
查看每个线程的详细信息:mysql》show processlist;对影响系统运行的线程:kill connection|query threadid的命令杀死。
-mysql能抗住多少tps

mysql 最大并发能达到多少


mysql
默认的最大并发连接为100,默认的连接数无法满足大量client
连接的请求.
但是可以通过以下方式改变,使用root用户登录mysql
系统引用mysql

show
variables
like
’max_connections‘;
+-----------------+-------+
|
Variable_name
|
Value
|
+-----------------+-------+
|
max_connections
|
100
|
+-----------------+-------+
在不需要重启的情况下.通过以下命令更改为300引用set
global
max_connections
=
300;为了保证mysql
重启能够生效,还需要编译
/my.ini
(默认)
把max_connections
=
300以上完成之后,下次重启就会使用新的参数。
-mysql能抗住多少tps

mysql tps 一般为多少


(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysql 》 show global status like ’Question%’;
(2)TPS(每秒事务量)
TPS = (Com_commit + Com_rollback) / seconds
mysql 》 show global status like ’Com_commit’;
mysql 》 show global status like ’Com_rollback’;
(3)key Buffer 命中率
mysql》show global status like ’key%’;
key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%
(4)InnoDB Buffer命中率
mysql》 show status like ’innodb_buffer_pool_read%’;
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%
(5)Query Cache命中率
mysql》 show status like ’Qcache%’;
Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;
(6)Table Cache状态量
mysql》 show global status like ’open%’;
比较 open_tables 与 opend_tables 值
(7)Thread Cache 命中率
mysql》 show global status like ’Thread%’;
mysql》 show global status like ’Connections’;
Thread_cache_hits = (1 - Threads_created / connections ) * 100%
(8)锁定状态
mysql》 show global status like ’%lock%’;
Table_locks_waited/Table_locks_immediate=0.3% 如果这个比值比较大的话,说明表锁造成的阻塞比较严重
Innodb_row_lock_waits innodb行锁,太大可能是间隙锁造成的
(9)复制延时量
mysql 》 show slave status
查看延时时间
(10) Tmp Table 状况(临时表状况)
mysql 》 show status like ’Create_tmp%’;
Created_tmp_disk_tables/Created_tmp_tables比值最好不要超过10%,如果Created_tmp_tables值比较大,
可能是排序句子过多或者是连接句子不够优化
(11) Binlog Cache 使用状况
mysql 》 show status like ’Binlog_cache%’;
如果Binlog_cache_disk_use值不为0 ,可能需要调大 binlog_cache_size大小
(12) Innodb_log_waits 量
mysql 》 show status like ’innodb_log_waits’;
Innodb_log_waits值不等于0的话,表明 innodb log buffer 因为空间不足而等待
比如命令:
》#show global status;
虽然可以使用:
》#show global status like %...%;
来过滤,但是对应长长的list,每一项都代表什么意思,还是有必要弄清楚
-mysql能抗住多少tps

数据库集群,主库提供写服务tps,整个集群的写服务和读服务分别是多少


利用mysql proxy来实现的。
MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询,而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 当然,主服务器也可以提供查询服务。使用读写分离最大的作用无非是环境服务器压力。
-mysql能抗住多少tps

MySQL字段何时拆分


第一种:将TPS分散,也就是需要将表进行分区到不同库(一般这样要考虑的东西太多。数据量不大一般不考虑)
第二种:使用能提供更高TPS的产品(这边建议 redis 是不错的选择)。
这边排除第一种
使用第二种:
更具时间经验值:一般使用redis 能提供 TPS:3-5W 更具机器情况还有所提高。
QPS:7-10W 更具机器情况还有所提高。
对于我们的TPS的情况 3-5W TPS 的redis一般能够胜任
这边主要担心的就是有关 持久化 的问题,这就是架构上需要设计的了。
redis 自身具有持久化功能,每秒持久化一次。
更具我们 同步的情况其实同步可以忍受短时间不实时现象。如果出现redis失效(宕机或怎么的可以重启redis重新同步所有数据)
可以搭建 redis的master-slave 或 cluster 都行这样就能很好的解决一台redis宕机问题。
可以根据 数据库软件设计的某些原理和借鉴秒杀架构,在后台不定期的将redis的数据同步到MySQL。
步骤可以有:
先将相关数据 格式化 的写入到日志文件(有能力提供消息队列更好)。
写入日志成功之后再将数据在redis做操作。确保出问题有数据库可查。
-mysql能抗住多少tps