红薯 MySQL 5.5 和 5.6 默认参数值的差异_MySQL
bitsCN.com
作为 MySQL 5.5 和 5.6 性能比较的一部分,我研究了下两个版本默认参数的差异,为了了解差异内容,我使用如下的 SQL 语句分别在 MySQL 5.5 和 5.6 版本进行查询,得出下表(点击图片查看大图):
让我们来看看这些差异的配置中最重要的也是影响最大的部分:
performance_schema 在 MySQL 5.6 中默认是开启的,但相关的很多参数相比 MySQL 5.5 却是降低了,例如 performance_schema 自动调整到 445 个表和 224 线程,比 MySQL 5.5 低。尽管默认 max_connections 只是 150 ,比 200 还小。
innodb_stats_on_metadata 在 MySQL 5.6 默认关闭,使得 information_schema 的查询速度快很多。
innodb_log_file_size – 默认值从 5MB 提升到 50MB,这是一个好的改变,虽然我觉得这个默认数值还可以再大些。对于写负载高的情况下,默认配置的 MySQL 5.6 性能更好。
back_log 改动比较小,从 50 改为 80。如果系统每秒处理的连接数很高,还需要继续提高这个配置的值。
open_files_limit 由原来的 1024 改为 5000
innodb_auto_extend_increment 由 8MB 改为 64MB,可帮助降低碎片。
max_connect_errors 从 10 改为 100,可降低潜在的连接堵塞,但还可以更高些。
sort_buffer_size 从 2M 将为 256K,这可避免小排序导致的资源浪费,但是对大的排序有负面的影响。
max_allowed_packet 从 1MB 改为 4MB 让 MySQL 可处理更大的查询。
join_buffer_size 从 128K 改为 256K,我觉得这个改动影响不大。
table_open_cache 从 400 提高到 2000,挺好!
innodb_buffer_pool_instances 从 1 改为 8,用于优化更高并发的负载。
query_cache_type 和 query_cache_size. The behavior is “no cache” by default still but it is achieved differently now. The query_cache_type is now off by default with default size of 1MB while in MySQL 5.5 and before it was “ON” by default with query cache size of 0 which makes it disabled. I wish query_cache_size though would be larger by default as value of 1M is too small to be practical if someone tries to enable it.
sql_mode has NO_ENGINE_SUBSTITUTION value by default which is good change as trying to create Innodb table but getting MyISAM because Innodb was disabled for some reason was very error prone gotcha. Note this is as far as MySQL 5.6 goes - STRICT_MODE and other safer behaviors are not enabled by default.
innodb_old_blocks_time 设置为 1000,很好的改变,默认扫描 InnoDB 缓冲池大小。
thread_cache_size 默认启用,对很多连接和断开连接操作的情况下有帮助。
sync_relay_log_info and sync_master_info 默认值有原来的 0 改为 10000. 该改动几乎不会影响负载。
secure_auth 默认开启,要求新的密码握手,特别是阻止老的不安全的做法,很好!
innodb_concurrency_tickets has been increased from 500 to 5000. If you’re using innodb_thread_concurrency this will reduce overhead associated with grabbing and releasing innodb_thread_concurrency slot but will increase potential starvation of queued threads especially for IO bound workloads. Most users will not be affected though as innodb_thread_concurrency is 0 by default so this queuing feature is disabled.
innodb_purge_threads 默认为 1 ,使用专用的后台 purge 线程,好!
innodb_open_files 由 300 改为 2000,好!
innodb_data_file_path got a small change with starting ibdata1 size raised from 10M to 12M. I’m not sure what is the purpose of this change but it is unlikely to have any practical meaning for users. Considering the default innodb_auto_extend_increment is 64 starting with 64M might have made more sense.
innodb_purge_patch_size 从 20 改为 300.
innodb_file_per_table 默认启用,这个改变很大,而且很棒。特别是当你的表非常大的时候。
optimizer_switch is the catch all variable for a lot of optimizer options. I wonder why was not it implemented as number of different variables which would make more sense in my opinion. MySQL 5.6 adds a lot more optimizer switches which you can play with:
01 |
mysql [localhost] {msandbox} (test) > select * from var55 where variable_name= 'OPTIMIZER_SWITCH' /G
|
02 |
*************************** 1. row *************************** |
03 |
VARIABLE_NAME: OPTIMIZER_SWITCH
|
04 |
VARIABLE_VALUE: index_merge= on ,index_merge_union= on ,index_merge_sort_union= on ,index_merge_intersection= on ,engine_condition_pushdown= on
|
05 |
1 row in set (0.00 sec)
|
06 |
07 |
mysql [localhost] {msandbox} (test) > select * from var56 where variable_name= 'OPTIMIZER_SWITCH' /G
|
08 |
*************************** 1. row *************************** |
09 |
VARIABLE_NAME: OPTIMIZER_SWITCH
|
10 |
VARIABLE_VALUE: index_merge= on ,index_merge_union= on ,index_merge_sort_union= on ,index_merge_intersection= on ,engine_condition_pushdown= on ,index_condition_pushdown= on ,mrr= on ,mrr_cost_based= on ,block_nested_loop= on ,batched_key_access= off ,materialization= on ,semijoin= on ,loosescan= on ,firstmatch= on ,subquery_materialization_cost_based= on ,use_index_extensions= on
|
11 |
1 row in set (0.00 sec)
|
总结: MySQL 5.6 对默认配置进行了一些微调,这些调整大多数都非常不错。
bitsCN.com
핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











이 기사는 Docker에서 MySQL 메모리 사용을 최적화합니다. 모니터링 기술 (Docker Stats, Performance Schema, 외부 도구) 및 구성 전략에 대해 설명합니다. 여기에는 Docker 메모리 제한, 스와핑 및 CGroups와 함께 포함됩니다

이 기사에서는 MySQL의 "공유 라이브러리를 열 수 없음"오류를 다룹니다. 이 문제는 MySQL이 필요한 공유 라이브러리 (.so/.dll 파일)를 찾을 수 없음에서 비롯됩니다. 솔루션은 시스템 패키지 M을 통한 라이브러리 설치 확인과 관련이 있습니다.

이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

이 기사는 Linux에 MySQL을 직접 설치하는 것과 Phpmyadmin이없는 Podman 컨테이너 사용을 비교합니다. 각 방법에 대한 설치 단계에 대해 자세히 설명하면서 Podman의 격리, 이식성 및 재현성의 장점을 강조하지만 또한

이 기사는 자체 포함 된 서버리스 관계형 데이터베이스 인 SQLITE에 대한 포괄적 인 개요를 제공합니다. SQLITE의 장점 (단순성, 이식성, 사용 용이성) 및 단점 (동시성 제한, 확장 성 문제)에 대해 자세히 설명합니다. 기음

이 안내서는 Homebrew를 사용하여 MacOS에 여러 MySQL 버전을 설치하고 관리하는 것을 보여줍니다. 홈 브루를 사용하여 설치를 분리하여 갈등을 방지하는 것을 강조합니다. 이 기사에는 설치, 서비스 시작/정지 서비스 및 Best Pra에 대해 자세히 설명합니다

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].
