mysql造数据占用临时表空间

MySQL在处理复杂查询时,有时会使用临时表来存储中间结果。当这些临时表占用大量空间时,可能导致性能下降甚至服务中断。本文将深入探讨临时表空间的占用问题,分析常见问题,指出易错点,并提供避免和优化的策略。
在这里插入图片描述

临时表空间的作用

  1. 排序(ORDER BY) :当查询需要对结果集进行排序时,MySQL可能创建临时表来存储排序后的数据。
  2. 分组(GROUP BY) :处理分组查询时,如果没有唯一索引,MySQL可能使用临时表。
  3. 连接(JOIN) :在多表连接操作中,如果无法优化成索引连接,也可能使用临时表。

常见问题与易错点

  1. 内存限制:MySQL默认使用内存中的临时表,但当数据量超出内存限制时,会转存到磁盘上的临时表空间。
  2. 未优化的查询:不恰当的查询设计可能导致大量临时表的生成,如无谓的全表扫描、未充分利用索引等。
  3. 数据类型不当:如果列的数据类型过大,临时表占用的空间也会相应增大。
  4. 临时表的清理:如果长时间运行的事务导致临时表占用过多空间,可能影响其他用户。

如何避免临时表空间的过度占用

  1. 优化查询

    • 使用EXPLAIN分析查询计划,避免全表扫描。
    • ORDER BYGROUP BY子句中使用索引。
    • 避免使用DISTINCT,除非绝对必要。
    • 优化连接条件,尽量使用索引连接。
  2. 调整系统参数

    • 增大tmp_table_sizemax_heap_table_size,允许更大的内存临时表。
    • 调整innodb_temp_data_file_path,扩大临时文件空间。
    • 注意,增大内存参数可能导致服务器内存压力增加,需谨慎。
  3. 数据类型优化

    • 尽可能使用较小的数据类型,减少存储空间。
    • 对于VARCHAR,确保长度合适,避免浪费空间。
  4. 事务管理

    • 及时提交事务,释放临时表空间。
    • 避免长时间运行的事务。

代码示例

以下是一个可能导致临时表空间占用的例子:

SELECT column1, column2, column3
FROM table1
JOIN table2 ON table1.id = table2.id
WHERE column4 = 'value'
ORDER BY column5;

优化后的版本:

CREATE INDEX idx_table1_column4 ON table1(column4);
CREATE INDEX idx_table2_column4 ON table2(column4);

SELECT column1, column2, column3
FROM table1
USE INDEX(idx_table1_column4)
JOIN table2 USE INDEX(idx_table2_column4) ON table1.id = table2.id
WHERE column4 = 'value'
ORDER BY column5
LIMIT 100;

在这个例子中,我们为column4创建了索引,强制使用这些索引进行连接和过滤,从而减少临时表的使用。同时,加上LIMIT限制结果数量,避免一次性处理大量数据。

使用并行查询和分区表

  1. 并行查询:MySQL 8.0 引入了并行查询,可以将大型查询拆分为子任务并行执行,降低临时表空间的占用。不过,这需要合理配置thread_pool_sizequery_alloc_block_size等参数。
  2. 分区表:对于大型表,使用分区可以将数据分成较小、更易管理的部分。在某些情况下,分区可以避免创建临时表,尤其是在GROUP BYORDER BY操作中。
CREATE TABLE large_table (
    ...
) PARTITION BY RANGE (year_column);

监控与调试

  1. 监控临时表空间:使用SHOW STATUS LIKE 'Created_tmp_tables%'SHOW VARIABLES LIKE 'tmpdir'来监控临时表的使用情况。
  2. 日志分析:启用慢查询日志,找出那些可能导致大量临时表的查询,进行优化。
  3. 性能分析:使用EXPLAIN EXTENDEDSHOW WARNINGS来获取查询执行的详细信息,包括是否使用了临时表。

实时续写与智能问答

在日常开发中,可以借助阿里云的通义灵码(Tongyi Lingma)这样的智能编码助手,进行实时续写和智能问答。例如,如果你在编写SQL查询时遇到困难,可以输入一部分查询语句,然后让通义灵码帮你完成剩余部分,或者询问关于临时表空间的问题,它会给出详细的解答和建议。

SELECT ...
FROM ...
WHERE ...
-- 输入到这里,然后让通义灵码续写

> 通义灵码,如何检查MySQL查询是否使用了临时表?

通义灵码:您可以使用`EXPLAIN EXTENDED`关键字在查询前进行预分析,然后查看`Using temporary`字段。如果该字段值为`YES`,则表示查询会使用临时表。

使用InnoDB的内存池

  1. InnoDB缓冲池:InnoDB引擎有自己的内存池,用于缓存数据和索引页,合理调整innodb_buffer_pool_size,可以减少磁盘I/O,间接减少临时表的磁盘使用。

实时跟踪与调整

  1. 性能监控:使用Percona Monitoring and Management (PMM)、MySQL Enterprise Monitor等工具,实时监控数据库性能,包括临时表空间的使用情况。
  2. 动态调整参数:在不影响服务的情况下,可以动态调整tmp_table_sizemax_heap_table_size,根据实际负载进行优化。

代码示例:监控临时表空间使用

SELECT variable_name, variable_value
FROM information_schema.global_status
WHERE variable_name IN ('Created_tmp_tables', 'Created_tmp_disk_tables');

此查询返回当前会话创建的临时表数量,以及在磁盘上创建的临时表数量。

最后的话

优化MySQL的临时表空间使用是一项持续的任务,需要结合业务需求、数据库设计和性能监控等多个方面进行综合考虑。通过合理的架构设计、代码优化、监控策略和智能工具的运用,我们可以有效管理和降低临时表空间的占用,从而提升系统的稳定性和性能。

  • 73
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
[client] port = 3306 socket=/home/mysql/data/mysql.sock [mysqld] lower_case_table_names=1 user = mysql #--- MySQL的管理用户 port = 3306 #--- 端口 #basedir=/usr/local/mysql socket=/home/mysql/data/mysql.sock #-- 启动的sock文件 datadir=/home/mysql/data log-bin=/home/mysql/mysql-bin log-error=/home/mysql/log/mysqld.log pid-file =/home/mysql/mysqld.pid bind-address = 0.0.0.0 server-id = 1 #示是本机的序号为1,一般来讲就是master的意思 skip-grant-tables skip-name-resolve # 禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项, # 则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求 #skip-networking back_log = 600 # MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用, # 然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。 # 如果期望在一个短时间内有很多连接,你需要增加它。也就是说,如果MySQL的连接数据达到max_connections时,新来的请求将会被存在堆栈中, # 以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过back_log,将不被授予连接资源。 # 另外,这值(back_log)限于您的操作系统对到来的TCP/IP连接的侦听队列的大小。 # 你的操作系统在这个队列大小上有它自己的限制(可以检查你的OS文档找出这个变量的最大值),试图设定back_log高于你的操作系统的限制将是无效的。 max_connections = 500 # MySQL的最大连接数,如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。可以过'conn%'通配符查看当前状态的连接数量,以定夺该值的大小。 max_connect_errors = 6000 # 对于同一主机,如果有超出该参数值个数的中断错误连接,则该主机将被禁止连接。如需对该主机进行解禁,执行:FLUSH HOST。 open_files_limit = 65535 # MySQL打开的文件描述符限制,默认最小1024;当open_files_limit没有被配置的时候,比较max_connections*5和ulimit -n的值,哪个大用哪个, # 当open_file_limit被配置的时候,比较open_files_limit和max_connections*5的值,哪个大用哪个. table_open_cache = 128 # MySQL每打开一个,都会读入一些数据到table_open_cache缓存中,当MySQL在这个缓存中找不到相应信息时,才会去磁盘上读取。默认值64 # 假定系统有200个并发连接,则需将此参数设置为200*N(N为每个连接所需的文件描述符数目); # 当把table_open_cache设置为很大时,如果系统处理不了那么多文件描述符,那么就会出现客户端失效,连接不上 max_allowed_packet = 1000000000 # 接受的数据包大小;增加该变量的值十分安全,这是因为仅当需要时才会分配额外内存。例如,仅当你发出长查询或MySQLd必须返回大的结果行时MySQLd才会分配更多内存。 # 该变量之所以取较小默认值是一种预防措施,以捕获客户端和服务器之间的错误信息包,并确保不会因偶然使用大的信息包而导致内存溢出。 binlog_cache_size = 1M # 一个事务,在没有提交的时候,产生的日志,记录到Cache中;等到事务提交需要提交的时候,则把日志持久化到磁盘。默认binlog_cache_size大小32K max_heap_table_size = 67108864 # 定义了用户可以创建的内存(memory table)的大小。这个值用来计算内存的最大行数值。这个变量支持动态改变 tmp_table_size = 67108864 # MySQL的heap(堆积)缓冲大小。所有联合在一个DML指令内完成,并且大多数联合甚至可以不用临时即可以完成。 # 大多数临时是基于内存的(HEAP)。具有大的记录长度的临时 (所有列的长度的和)或包含BLOB列的存储在硬盘上。 # 如果某个内部heap(堆积)大小超过tmp_table_size,MySQL可以根据需要自动将内存中的heap改为基于硬盘的MyISAM。还可以通过设置tmp_table_size选项来增加临时的大小。也就是说,如果调高该值,MySQL同时将增加heap的大小,可达到提高联接查询速度的效果 read_buffer_size = 4194304 # MySQL读入缓冲区大小。对进行顺序扫描的请求将分配一个读入缓冲区,MySQL会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。 # 如果对的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能 read_rnd_buffer_size = 4194304 # MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时, # MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大 sort_buffer_size = 4194304 # MySQL执行排序使用的缓冲大小。如果想要增加ORDER BY的速度,首先看是否可以让MySQL使用索引而不是额外的排序阶段。 # 如果不能,可以尝试增加sort_buffer_size变量的大小 join_buffer_size = 8388608 # 联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享 thread_cache_size = 8 # 这个值(默认8)示可以重新利用保存在缓存中线程的数量,当断开连接时如果缓存中还有空间,那么客户端的线程将被放到缓存中, # 如果线程重新被请求,那么请求将从缓存中读取,如果缓存中是空的或者是新的请求,那么这个线程将被重新创建,如果有很多新的线程, # 增加这个值可以改善系统性能.通过比较Connections和Threads_created状态的变量,可以看到这个变量的作用。(–>示要调整的值) # 根据物理内存设置规则如下: # 1G —> 8 # 2G —> 16 # 3G —> 32 # 大于3G —> 64 #query_cache_size = 8M #MySQL的查询缓冲大小(从4.0.1开始,MySQL提供了查询缓冲机制)使用查询缓冲,MySQL将SELECT语句和查询结果存放在缓冲区中, # 今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。根据MySQL用户手册,使用查询缓冲最多可以达到238%的效率。 # 通过检查状态值'Qcache_%',可以知道query_cache_size设置是否合理:如果Qcache_lowmem_prunes的值非常大,则明经常出现缓冲不够的情况, # 如果Qcache_hits的值也非常大,则明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则明你的查询重复率很低, # 这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确示不使用查询缓冲 #query_cache_limit = 2M #指定单个查询能够使用的缓冲区大小,默认1M key_buffer_size = 1048576 #指定用于索引的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大, # 系统将开始换页并且真的变慢了。对于内存在4GB左右的服务器该参数可设置为384M或512M。通过检查状态值Key_read_requests和Key_reads, # 可以知道key_buffer_size设置是否合理。比例key_reads/key_read_requests应该尽可能的低, # 至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE 'key_read%'获得)。注意:该参数值设置的过大反而会是服务器整体效率降低 ft_min_word_len = 4 # 分词词汇最小长度,默认4 transaction_isolation = REPEATABLE-READ # MySQL支持4种事务隔离级别,他们分别是: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. # 如没有指定,MySQL默认采用的是REPEATABLE-READ,ORACLE默认的是READ-COMMITTED log_bin = mysql-bin binlog_format = mixed expire_logs_days = 30 #超过30天的binlog删除 slow_query_log = 1 long_query_time = 1 #慢查询时间 超过1秒则为慢查询 slow_query_log_file = /home/mysql/data/mysql-slow.log performance_schema = 0 explicit_defaults_for_timestamp #lower_case_table_names = 1 #不区分大小写 skip-external-locking #MySQL选项以避免外部锁定。该选项默认开启 default-storage-engine = InnoDB #默认存储引擎 innodb_file_per_table = 1 # InnoDB为独立空间模式,每个数据库的每个都会生成一个数据空间 # 独立空间优点: # 1.每个都有自已独立的空间。 # 2.每个数据和索引都会存在自已的空间中。 # 3.可以实现单在不同的数据库中移动。 # 4.空间可以回收(除drop table操作处,空不能自已回收) # 缺点: # 单增加过大,如超过100G # 结论: # 共享空间在Insert操作上少有优势。其它都没独立空间现好。当启用独立空间时,请合理调整:innodb_open_files innodb_open_files = 500 # 限制Innodb能打开的数据,如果库里的特别多的情况,请增加这个。这个值默认是300 innodb_buffer_pool_size = 1048576 # InnoDB使用一个缓冲池来保存索引和原始数据, 不像MyISAM. # 这里你设置越大,你在存取里面数据时所需要的磁盘I/O越少. # 在一个独立使用的数据库服务器上,你可以设置这个变量到服务器物理内存大小的80% # 不要设置过大,否则,由于物理内存的竞争可能导致操作系统的换页颠簸. # 注意在32位系统上你每个进程可能被限制在 2-3.5G 用户层面内存限制, # 所以不要设置的太高. innodb_write_io_threads = 4 innodb_read_io_threads = 4 # innodb使用后台线程处理数据页上的读写 I/O(输入输出)请求,根据你的 CPU 核数来更改,默认是4 # 注:这两个参数不支持动态改变,需要把该参数加入到my.cnf里,修改完后重启MySQL服务,允许值的范围从 1-64 innodb_thread_concurrency = 0 # 默认设置为 0,示不限制并发数,这里推荐设置为0,更好去发挥CPU多核处理能力,提高并发量 innodb_purge_threads = 1 # InnoDB中的清除操作是一类定期回收无用数据的操作。在之前的几个版本中,清除操作是主线程的一部分,这意味着运行时它可能会堵塞其它的数据库操作。 # 从MySQL5.5.X版本开始,该操作运行于独立的线程中,并支持更多的并发数。用户可通过设置innodb_purge_threads配置参数来选择清除操作是否使用单 # 独线程,默认情况下参数设置为0(不使用单独线程),设置为 1 时示使用单独的清除线程。建议为1 innodb_flush_log_at_trx_commit = 2 # 0:如果innodb_flush_log_at_trx_commit的值为0,log buffer每秒就会被刷写日志文件到磁盘,提交事务的时候不做任何操作(执行是由mysql的master thread线程来执行的。 # 主线程中每秒会将重做日志缓冲写入磁盘的重做日志文件(REDO LOG)中。不论事务是否已经提交)默认的日志文件是ib_logfile0,ib_logfile1 # 1:当设为默认值1的时候,每次提交事务的时候,都会将log buffer刷写到日志。 # 2:如果设为2,每次提交事务都会写日志,但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是,并不能保证100%每秒一定都会刷到磁盘,这要取决于进程的调度。 # 每次事务提交的时候将数据写入事务日志,而这里的写入仅是调用了文件系统的写入操作,而文件系统是有 缓存的,所以这个写入并不能保证数据已经写入到物理磁盘 # 默认值1是为了保证完整的ACID。当然,你可以将这个配置项设为1以外的值来换取更高的性能,但是在系统崩溃的时候,你将会丢失1秒的数据。 # 设为0的话,mysqld进程崩溃的时候,就会丢失最后1秒的事务。设为2,只有在操作系统崩溃或者断电的时候才会丢失最后1秒的数据。InnoDB在做恢复的时候会忽略这个值。 # 总结 # 设为1当然是最安全的,但性能页是最差的(相对其他两个参数而言,但不是不能接受)。如果对数据一致性和完整性要求不高,完全可以设为2,如果只最求性能,例如高并发写的日志服务器,设为0来获得更高性能 innodb-buffer-pool-size = 128M innodb_log_buffer_size = 4194304 # 此参数确定些日志文件所用的内存大小,以M为单位。缓冲区更大能提高性能,但意外的故障将会丢失数据MySQL开发人员建议设置为1-8M之间 innodb_log_file_size = 268435456 # 此参数确定数据日志文件的大小,更大的设置可以提高性能,但也会增加恢复故障数据库所需的时间 innodb_log_files_in_group = 3 # 为提高性能,MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3 innodb_max_dirty_pages_pct = 90 # innodb主线程刷新缓存池中的数据,使脏数据比例小于90% innodb_lock_wait_timeout = 120 # InnoDB事务在被回滚之前可以等待一个锁定的超时秒数。InnoDB在它自己的锁定中自动检测事务死锁并且回滚事务。InnoDB用LOCK TABLES语句注意到锁定设置。默认值是50秒 bulk_insert_buffer_size = 1024M # 批量插入缓存大小, 这个参数是针对MyISAM存储引擎来说的。适用于在一次性插入100-1000+条记录时, 提高效率。默认值是8M。可以针对数据量的大小,翻倍增加。 myisam_sort_buffer_size = 1024M # MyISAM设置恢复之时使用的缓冲区的尺寸,当在REPAIR TABLE或用CREATE INDEX创建索引或ALTER TABLE过程中排序 MyISAM索引分配的缓冲区 myisam_max_sort_file_size = 10G # 如果临时文件会变得超过索引,不要使用快速排序索引方法来创建一个索引。注释:这个参数以字节的形式给出 myisam_repair_threads = 1 # 如果该值大于1,在Repair by sorting过程中并行创建MyISAM索引(每个索引在自己的线程内) interactive_timeout = 28800 # 服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。默认值:28800秒(8小时) wait_timeout = 28800 # 服务器关闭非交互连接之前等待活动的秒数。在线程启动时,根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值, # 取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。参数默认值:28800秒(8小时) # MySQL服务器所支持的最大连接数是有上限的,因为每个连接的建立都会消耗内存,因此我们希望客户端在连接到MySQL Server处理完相应的操作后, # 应该断开连接并释放占用的内存。如果你的MySQL Server有大量的闲置连接,他们不仅会白白消耗内存,而且如果连接一直在累加而不断开, # 最终肯定会达到MySQL Server的连接上限数,这会报'too many connections'的错误。对于wait_timeout的值设定,应该根据系统的运行情况来判断。 # 在系统运行一段时间后,可以通过show processlist命令查看当前系统的连接状态,如果发现有大量的sleep状态的连接进程,则说明该参数设置的过大, # 可以进行适当的调整小些。要同时设置interactive_timeout和wait_timeout才会生效。 [mysqldump] quick max_allowed_packet = 16M #服务器发送和接受的最大包长度 [myisamchk] key_buffer_size = 8M sort_buffer_size = 8M read_buffer = 4M write_buffer = 4M
去年十月,TiDB 1.0 版本发布,在接下来的六个月中,开发团队一方面在维护 1.0 版本的稳定性并且增加必要的新特性,另一方面马不停蹄的开发 2.0 版本。经过 6 个 RC 版本,TiDB 2.0 GA 版本于 4 月 27 日正式发布。 2.0 版本规划 根据现有用户的情况、技术发展趋势以及社区的声音,TiDB 2.0 版本主要聚焦在以下几点: 保证 TiDB 的稳定性以及正确性。这两点是一个数据库软件的基础功能,作为业务的基石,任何一点抖动或者错误都可能对业务成巨大的影响。目前已经有大量的用户在线上使用 TiDB,这些用户的数据量在不断增加、业务也在不断演进。 提升 TiDB 在大数据量下的查询性能。TiDB 目前很多客户都有少则上百 GB,多则上百 TB 的数据,一方面数据会持续增加,另一方面也希望能对这些数据做实时的查询。所以如果能提升大数据量下的查询性能,对用户会很有帮助。 优化 TiDB 的易用性和可维护性。TiDB 整套系统的复杂性比较高,运维及使用的难度要大于单机数据库,所以希望能提供尽可能方便的方案帮助用户使用 TiDB。比如尽可能简化部署、升级、扩容方式,尽可能容易的定位系统中出现的异常状态。 围绕上面三点原则,TiDB 做了大量的改进,一些是对外可见,如 OLAP 性能的显著提升、监控项的大量增加以及运维工具的各项优化,还有更多的改进是隐藏在数据库背后,默默的提升整个数据库的稳定性以及正确性。 正确性和稳定性 在 1.0 版本发布之后,TiDB 开始构建和完善自动化测试平台 Schrodinger,彻底告别了之前靠手工部署集群测试的方式。同时也新增了非常多的测试用例,做到测试从最底层 RocksDB,到 Raft,再到 Transaction,然后是 SQL 都能覆盖。 在 Chaos 测试上面,TiDB 引入了更多的错误注入工具,例如使用 systemtap 对 I/O 进行 delay 等,也在代码特定的业务的逻辑进行错误注入测试,充分保证 TiDB 在异常条件下面也能稳定运行。 TiDB 的开发团队之前做了很多 TLA+ 的论证工作,也有一些简单的测试,1.0 之后开始使用 TLA+ 系统进行论证,保证所做的实现在设计上面都是正确的。 在存储引擎方面,为了提升大规模集群的稳定性和性能,TiDB 优化了 Raft 的流程,引入 Region Merge、Raft Learner 等新特性;优化热点调度机制,统计更多的信息,并根据这些信息做更合理的调度;优化 RocksDB 的性能,使用 DeleteFilesInRanges 等特性,提升空间回收效率,降低磁盘负载,以及更加平滑地使用磁盘资源等等。 OLAP 性能优化 TiDB 2.0 版本重构了 SQL 优化器和执行引擎,希望能尽可能快的选择最优查询计划并且尽可能高效地执行查询计划。 1.0 版本已经从基于规则的查询优化器转向基于代价的查询优化器,但是还不够完善,在 2.0 版本中,一方面优化统计信息的精确度以及更新及时程度,另一方面提升 SQL 优化器的能力,对查询代价的估算更加精准、对复杂过滤条件的分析更加细致、对关联子查询的处理更加优雅、对物理算子的选择更加灵活准确。 在这一版本中,SQL 执行引擎引入新的内部数据示方式 --- `Chunk`,一个结构中保存一批数据而不仅是一行数据,同一列的数据在内存中连续存放,使得内存使用更紧凑,这样带来了几点好处:1. 显著减小了内存消耗; 2. 批量分配内存,减小了 GC 开销;3. 算子之间可以对数据进行批量传递,减小调用开销;4. 在某些场景下,可以进行向量计算以及减小 CPU 的 Cache Miss 的情况。 完成上述两项改动之后,TiDB 在 OLAP 场景下的性能有了大幅的质的提升,从 TPC-H 的对比结果来看,所有的 Query 在 2.0 中都运行得更快,一些 Query 大多数都有几倍甚至数量级的提升,特别是一些 1.0 中跑不出结果的 Query 在 2.0 中都能顺利执行。 易用性和可运维性 为了更容易被安装和使用,TiDB 2.0 在监控、运维、工具方面也做了诸多优化。 在监控方面,增加了过百个监控项,同时通过 HTTP 接口、SQL 语句等方式暴露出一些运行时信息,用于系统调优或者是定位系统中存在的问题。 在运维方面,运维工具做了优化,简化操作流程,降低操作复杂度及操作过程对于线上的影响。同时功能也更加丰富,支持自动部署 Binlog 组件、支持启用 TLS。 2.0 详细更新列 TiDB: 1.SQL 优化器 精简统计信息数据结构,减小内存占用 加快进程启动时加载统计信息速度 支持统计信息动态更新 [experimental] 优化代价模型,对代价估算更精准 使用 `Count-Min Sketch` 更精确地估算点查的代价 支持分析更复杂的条件,尽可能充分的使用索引 支持通过 `STRAIGHT_JOIN` 语法手动指定 Join 顺序 `GROUP BY`子句为空时使用 Stream Aggregation 算子,提升性能 支持使用索引计算 `Max/Min` 函数 优化关联子查询处理算法,支持将更多类型的关联子查询解关联并转化成 `Left Outer Join` 扩大 `IndexLookupJoin` 的使用范围,索引前缀匹配的场景也可以使用该算法 2.SQL 执行引擎 使用 Chunk 结构重构所有执行器算子,提升分析型语句执行性能,减少内存占用,显著提升 TPC-H 结果 支持 Streaming Aggregation 算子下推 优化 `Insert Into Ignore` 语句性能,提升 10 倍以上 优化 `Insert On Duplicate Key Update` 语句性能,提升 10 倍以上 下推更多的数据类型和函数到 TiKV 计算 优化 `Load Data` 性能,提升 10 倍以上 支持对物理算子内存使用进行统计,通过配置文件以及系统变量指定超过阈值后的处理行为 支持限制单条 SQL 语句使用内存的大小,减少程序 OOM 风险 支持在 CRUD 操作中使用隐式的行 ID 提升点查性能 3.Server 支持 Proxy Protocol 添加大量监控项, 优化日志 支持配置文件的合法性检测 支持 HTTP API 获取 TiDB 参数信息 使用 Batch 方式 Resolve Lock,提升垃圾回收速度 支持多线程垃圾回收 支持 TLS 4.兼容性 支持更多 MySQL 语法 支持配置文件修改 `lower_case_table_names` 系统变量,用于支持 OGG 数据同步工具 提升对 Navicat 的兼容性 在 `Information_Schema` 中支持显示建时间 修复部分函数/达式返回类型和 MySQL 不同的问题 提升对 JDBC 兼容性 支持更多的 `SQL_MODE` 5.DDL 优化 `Add Index` 的执行速度,部分场景下速度大幅度提升 `Add Index` 操作变更为低优先级,降低对线上业务影响 `Admin Show DDL Jobs` 输出更详细的 DDL 任务状态信息 支持 `Admin Show DDL Job Queries JobID` 查询当前正在运行的 DDL 任务的原始语句 支持 `Admin Recover Index` 命令,用于灾难恢复情况下修复索引数据 支持通过 `Alter` 语句修改 Table Options PD: 1.增加 `Region Merge` 支持,合并数据删除后产生的空 Region [experimental] 2.增加 `Raft Learner` 支持 [experimental] 3.调度器优化 调度器适应不同的 Region size 提升 TiKV 宕机时数据恢复的优先级和恢复速度 提升下线 TiKV 节点搬迁数据的速度 优化 TiKV 节点空间不足时的调度策略,尽可能防止空间不足时磁盘被写满 提升 balance-leader scheduler 的调度效率 减少 balance-region scheduler 调度开销 优化 hot-region scheduler 的执行效率 4.运维接口及配置 增加 TLS 支持 支持设置 PD leader 优先级 支持基于 label 配置属性 支持配置特定 label 的节点不调度 Region leader 支持手动 Split Region,可用于处理单 Region 热点的问题 支持打散指定 Region,用于某些情况下手动调整热点 Region 分布 增加配置参数检查规则,完善配置项的合法性较验 5.调试接口 增加 `Drop Region` 调试接口 增加枚举各个 PD health 状态的接口 6.统计相关 添加异常 Region 的统计 添加 Region 隔离级别的统计 添加调度相关 metrics 7.性能优化 PD leader 尽量与 etcd leader 保持同步,提升写入性能 优化 Region heartbeat 性能,现可支持超过 100 万 Region TiKV: 1.功能 保护关键配置,防止错误修改 支持 `Region Merge` [experimental] 添加 `Raw DeleteRange` API 添加 `GetMetric` API 添加 `Raw Batch Put`,`Raw Batch Get`,`Raw Batch Delete` 和 `Raw Batch Scan` 给 Raw KV API 增加 Column Family 参数,能对特定 Column Family 进行操作 Coprocessor 支持 streaming 模式,支持 streaming 聚合 支持配置 Coprocessor 请求的超时时间 心跳包携带时间戳 支持在线修改 RocksDB 的一些参数,包括 `block-cache-size` 大小等 支持配置 Coprocessor 遇到某些错误时的行为 支持以导数据模式启动,减少导数据过程中的写放大 支持手动对 region 进行对半 split 完善数据修复工具 tikv-ctl Coprocessor 返回更多的统计信息,以便指导 TiDB 的行为 支持 ImportSST API,可以用于 SST 文件导入 [experimental] 新增 TiKV Importer 二进制,与 TiDB Lightning 集成用于快速导入数据 [experimental] 2.性能 使用 ReadPool 优化读性能,`raw_get/get/batch_get` 提升 30% 提升 metrics 的性能 Raft snapshot 处理完之后立即通知 PD,加快调度速度 解决 RocksDB 刷盘导致性能抖动问题 提升在数据删除之后的空间回收 加速启动过程中的垃圾清理过程 使用 `DeleteFilesInRanges` 减少副本迁移时 I/O 开销 3.稳定性 解决在 PD leader 发送切换的情况下 gRPC call 不返回问题 解决由于 snapshot 导致下线节点慢的问题 限制搬移副本临时占用空间大小 如果有 Region 长时间没有 Leader,进行上报 根据 compaction 事件及时更新统计的 Region size 限制单次 scan lock 请求的扫描的数据量,防止超时 限制接收 snapshot 过程中的内存占用,防止 OOM 提升 CI test 的速度 解决由于 snapshot 太多导致的 OOM 问题 配置 gRPC 的 `keepalive` 参数 修复 Region 增多容易 OOM 的问题 此外,同时发布的还有 TiSpark 1.0 GA 版本。TiSpark 1.0 版本组件提供了针对 TiDB 上的数据使用 Apache Spark 进行分布式计算的能力。更新包括: 1.提供了针对 TiKV 读取的 gRPC 通信框架 2.提供了对 TiKV 组件数据的和通信协议部分的编码解码 3.提供了计算下推功能,包含 聚合下推 谓词下推 TopN 下推 Limit 下推 4.提供了索引相关支持 谓词转化聚簇索引范围 谓词转化次级索引 Index Only 查询优化 运行时索引退化扫优化 5.提供了基于代价优化 统计信息支持 索引选择 广播代价估算 6.多种 Spark Interface 的支持 Spark Shell 支持 ThriftServer/JDBC 支持 Spark-SQL 交互支持 PySpark Shell 支持 SparkR 支持 相关链接 TiDB 的详细介绍:点击查看 TiDB 的下载地址:点击下载

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Jimaks

您的鼓励将是我创作的最大动力!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值