ホームページ データベース mysql チュートリアル 红薯 MySQL 5.5 和 5.6 默认参数值的差异_MySQL

红薯 MySQL 5.5 和 5.6 默认参数值的差异_MySQL

Jun 01, 2016 pm 01:36 PM

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
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

Video Face Swap

Video Face Swap

完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

使いやすく無料のコードエディター

SublimeText3 中国語版

SublimeText3 中国語版

中国語版、とても使いやすい

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

神レベルのコード編集ソフト(SublimeText3)

MySQLの役割:Webアプリケーションのデータベース MySQLの役割:Webアプリケーションのデータベース Apr 17, 2025 am 12:23 AM

WebアプリケーションにおけるMySQLの主な役割は、データを保存および管理することです。 1.MYSQLは、ユーザー情報、製品カタログ、トランザクションレコード、その他のデータを効率的に処理します。 2。SQLクエリを介して、開発者はデータベースから情報を抽出して動的なコンテンツを生成できます。 3.MYSQLは、クライアントサーバーモデルに基づいて機能し、許容可能なクエリ速度を確保します。

Innodb Redoログの役割を説明し、ログを元に戻します。 Innodb Redoログの役割を説明し、ログを元に戻します。 Apr 15, 2025 am 12:16 AM

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

MySQL:世界で最も人気のあるデータベースの紹介 MySQL:世界で最も人気のあるデータベースの紹介 Apr 12, 2025 am 12:18 AM

MySQLはオープンソースのリレーショナルデータベース管理システムであり、主にデータを迅速かつ確実に保存および取得するために使用されます。その実用的な原則には、クライアントリクエスト、クエリ解像度、クエリの実行、返品結果が含まれます。使用法の例には、テーブルの作成、データの挿入とクエリ、および参加操作などの高度な機能が含まれます。一般的なエラーには、SQL構文、データ型、およびアクセス許可、および最適化の提案には、インデックスの使用、最適化されたクエリ、およびテーブルの分割が含まれます。

MySQLの場所:データベースとプログラミング MySQLの場所:データベースとプログラミング Apr 13, 2025 am 12:18 AM

データベースとプログラミングにおけるMySQLの位置は非常に重要です。これは、さまざまなアプリケーションシナリオで広く使用されているオープンソースのリレーショナルデータベース管理システムです。 1)MySQLは、効率的なデータストレージ、組織、および検索機能を提供し、Web、モバイル、およびエンタープライズレベルのシステムをサポートします。 2)クライアントサーバーアーキテクチャを使用し、複数のストレージエンジンとインデックスの最適化をサポートします。 3)基本的な使用には、テーブルの作成とデータの挿入が含まれ、高度な使用法にはマルチテーブル結合と複雑なクエリが含まれます。 4)SQL構文エラーやパフォーマンスの問題などのよくある質問は、説明コマンドとスロークエリログを介してデバッグできます。 5)パフォーマンス最適化方法には、インデックスの合理的な使用、最適化されたクエリ、およびキャッシュの使用が含まれます。ベストプラクティスには、トランザクションと準備された星の使用が含まれます

なぜMySQLを使用するのですか?利点と利点 なぜMySQLを使用するのですか?利点と利点 Apr 12, 2025 am 12:17 AM

MySQLは、そのパフォーマンス、信頼性、使いやすさ、コミュニティサポートに選択されています。 1.MYSQLは、複数のデータ型と高度なクエリ操作をサポートし、効率的なデータストレージおよび検索機能を提供します。 2.クライアントサーバーアーキテクチャと複数のストレージエンジンを採用して、トランザクションとクエリの最適化をサポートします。 3.使いやすく、さまざまなオペレーティングシステムとプログラミング言語をサポートしています。 4.強力なコミュニティサポートを提供し、豊富なリソースとソリューションを提供します。

MySQL対その他のプログラミング言語:比較 MySQL対その他のプログラミング言語:比較 Apr 19, 2025 am 12:22 AM

他のプログラミング言語と比較して、MySQLは主にデータの保存と管理に使用されますが、Python、Java、Cなどの他の言語は論理処理とアプリケーション開発に使用されます。 MySQLは、データ管理のニーズに適した高性能、スケーラビリティ、およびクロスプラットフォームサポートで知られていますが、他の言語は、データ分析、エンタープライズアプリケーション、システムプログラミングなどのそれぞれの分野で利点があります。

MySQL:中小企業から大企業まで MySQL:中小企業から大企業まで Apr 13, 2025 am 12:17 AM

MySQLは、中小企業に適しています。 1)中小企業は、顧客情報の保存など、基本的なデータ管理にMySQLを使用できます。 2)大企業はMySQLを使用して、大規模なデータと複雑なビジネスロジックを処理して、クエリのパフォーマンスとトランザクション処理を最適化できます。

MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか? MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか? Apr 14, 2025 am 12:18 AM

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

See all articles