目次
Mysql技术内幕——InnoDB存储引擎
ホームページ データベース mysql チュートリアル Mysql技术内幕InnoDB存储引擎_MySQL

Mysql技术内幕InnoDB存储引擎_MySQL

Jun 01, 2016 pm 01:17 PM
テクノロジー

Mysql技术内幕——InnoDB存储引擎

http://jingyan.baidu.com/article/fedf07377c493f35ac89770c.html

一.mysql体系结构和存储引擎

1.1、数据库和实例的区别

 

数据库:物理操作系统或其他形式文件类型的集合。在mysql下数据库文件可以是frmmydmyiibd结尾的文件。

         数据库实例:由数据库后台进程/线程以及一个共享内存区组成。数据库实例才是真正用来操作数据库文件的。

         mysql数据库是单进程多线程的程序,与sql server比较类似。也就是说,Mysql数据库实例在系统上的表现就是一个进程。

1.2、mysql的体系结构

 

mysql由连接池组件、管理服务和工具组件、sql接口组建、查询分析器组件、优化器组件、缓存组件、插件是存储引擎、物理文件。

1.3、mysql存储引擎

      1.3.1、innodb存储引擎,特点支持外键、行锁、非锁定读(默认情况下读取不会产生锁)、mysql-4.1开始支持每个innodb引擎的表单独放到一个表空间里。innodb通过使用MVCC来获取高并发性,并且实现sql标准的4种隔离级别,同时使用一种被称成next-key locking的策略来避免换读(phantom)现象。除此之外innodb引擎还提供了插入缓存(insert buffer)、二次写(double write)、自适应哈西索引(adaptive hash index)、预读(read ahead)等高性能技术。

      1.3.2、myisam存储引擎,myisam特点是不支持事物,适合olap应用,myisam表由MYD和MYI组成。mysql-5.0版本之前,myisam默认支持的表大小为4G,从mysql-5.0以后,myisam默认支持256T的表单数据。myisam只缓存索引数据。

      1.3.3、NDB存储引擎,特点是数据放在内存中,mysql-5.1版本开始可以将非索引数据放到磁盘上。NDB之前的缺陷是join查询是mysql数据库层完成的,而不是存储引擎完成的,复杂的join查询需要巨大的网络开销,速度很慢。当前mysql cluster7.2版本中已经解决此问题,join查询效率提高了70倍。

      1.3.4、memeory存储引擎,将数据放到内存中,默认使用hash索引,不支持text和blob类型,varchara是按照char的方式来存储的。mysql数据库使用memory存储引擎作为临时表还存储中间结果集(intermediate result),如果中间集结果大于memorg表的容量设置,又或者中间结果集包含text和blog列类型字段,则mysql会把他们转换到myisam存储引擎表而放到磁盘上,会对查询产生性能影响。

      1.3.5、archive存储引擎,压缩能力较强,主要用于归档存储。

      1.3.6、federated存储引擎,不存储数据,他指向一台远程mysql数据库上的表。

      1.3.7、maria存储引擎,myisam的后续版本,支持缓存数据和索引,行锁设计,支持mvcc,支持事务和非事务安全的选项,以及更好的BLOG字符类型的处理性能。

      1.3.8、其他存储引擎,sphinx用于全文索引,infobright用于数据仓库。

1.4连接Mysql

1.4.1、TCP/IP:基于网络的连接,连接进行权限检查。

         1.4.2、命名管道和共享内存:Windows系统上同一服务器上的两进程可通过命名管道连接,需在配置文件中启用--enable-named-pipe选项。

         1.4.3、Unix套接字:客户端与服务端位于同一服务器时才可使用,可以在my.cnf中指定-socket=/tmp/mysql.sock,连接时指定./mysql -S/tmp/mysql.sock。

二.InnoDB存储引擎

2.2、innodb引擎架构

       InnoDB的多个内存块组成了内存池,负责如下工作:

1).维护所有进程/线程需要访问的多个内部数据结构。

      2).缓存磁盘上的数据,方便快速的读取,并且在对磁盘文件的数据进行修改之前在这里缓存。

      3).重做日志缓存。

      后台线程的主要作用是负责刷新内存池中的数据,保证缓冲池中的内存缓存是最近的数据,此外、将已经修改的数据文件刷新到磁盘文件

      2.2.1、后台线程

      innodb存储引擎后台有7个线程,—–4个IO线程(insert buffer thread,log thread,read thread,write thread),1个master thread,一个lock监控线程,一个错误监控线程。

      2.2.2、内存

      innodb存储引擎内存由以下三个部分组成:缓冲池(buffer pool),重做日志缓存(redo log buffer),额外的内存池(additional memory pool)。可以使用 show engine innodb status来查看innodb_buffer_pool的使用情况。

      innodb_buffer_pool_size:具体看,缓冲池中的数据库类型有:索引页、数据库页、undo页、插入缓存页(insert buffer)、自适应hash(adaptive hashindex)、innodb存储的锁信息(lock info)、数据字典信息(data dictionary)。

         InnoDB工作方式:将数据文件按页(每页16K)读入InnoDBbuffer pool,然后按最近最少使用算法(LRU)保留缓存数据,最后通过一定频率将脏页刷新到文件。

 

 

2.3、master thread

      2.3.1、master thread源码分析

 

      2.3.2、master thread的潜在问题

      1、由于硬件的发展,现在的硬件性能已经提高了很多,如果innodb每秒最大刷新100个脏页,那么效率会很低,为了解决这个问题,innodb plugin提供了一个参数innodb_io_capacity,用来表示磁盘IO的吞吐量,默认值是200,规则如下:在合并插入缓存时,合并插入缓存的数量为innodb_io_capacity的5%;在从缓冲区刷新脏页时,啥新脏页的数量为innodb_io_capacity。

      2、关于innodb_max_dirty_pages_pct值的争议,如果值过大,内存也很大或者服务器压力很大,那么效率很降低,如果设置的值过小,那么硬盘的压力会增加,建议是在75-80.并且innodb plugin引进了innodb_adaptive_flushng(自适应的刷新),该值影响每秒刷新脏页的数量。

2.4、关键特性,为innodb提高性能的技术

      2.4.1、插入缓存

      当一个表有非聚集索引时,对于非聚集索引的叶子节点的插入不是顺序的,这时候需要离散的访问非聚集索引页,性能就在这里降低了,这是由于b+树的原理导致的。插入缓存就是用来解决这个问题的。

      对于非聚集索引的插入和更新操作,不是每一次都直接插入索引页,而是先判断插入的非聚集索引页是否在缓存中,如果在就直接插入,如果不在就放入到一个插入缓冲区中,好似欺骗数据库这个非聚集索引已经插入到叶子节点了。然后再以一定的频率插入缓存和非聚集索引页字节点的合并操作。

      插入缓存的使用需要满足以下两个条件(也就是非唯一的辅助索引):索引是辅助索引;索引不是唯一的。

      2.4.2、两次写

      两次写给innodb带来的是可靠性,主要用来解决部分写失败(partial page write)。在应用重做日之前,我们需要一个页的副本,当写入失效发生时,先通过页的副本来还原该页,再进行重做,这就是doublewrite。

      doublewrite有两部分组成,一部分是内存中的doublewrite buffer,大小为2M,另外一部分就是物理磁盘上的共享表空间中联系的128个页,即两个区,大小同样为2M。当缓冲池的张也刷新时,并不直接写硬盘,而是回通过memcpy函数将脏页先拷贝到内存中的doublewrite buffer,之后通过doublewrite buffer再分两次写,每次写入1M到共享表空间的物理磁盘上,然后马上调用fsync函数,同步磁盘。

      2.4.3、自适应哈西索引

      由于innodb不支持hash索引,但是在某些情况下hash索引的效率很高,于是出现了 adaptive hash index功能,innodb存储引擎会监控对表上索引的查找,如果观察到建立hash索引可以提高性能的时候,则自动建立hash索引。

2.5、启动、关闭、恢复

innodb_fast_shutdown影响InnoDB表关闭。该参数有0、1、2三个参数。

      0 MySQL关闭时  完成所有的full purge和merge insertbuffer操作

         1默认值 只将缓冲池内的一些脏页刷新至磁盘

         2将日志都写入日志文件不会有任何事务丢失但下次启动时会进行recovery

      innodb_force_recovery影响整个innodb存储引擎的恢复状况,该值默认为0,表示当需要恢复时,需要执行所有的恢复操作,当不能进行有效恢复时,如数据页发生了corruption,mysql数据库可能宕机,并把错误写入错误日志中。

三.文件

3.1参数文件

      Mysql实例可以不需要参数文件,这是所有的参数值取决于编译Mysql时指定的默认值和源代码中指定参数的默认值。其参数文件是Mysql.cnf。

3.1.1、什么是参数

      参数是一个键/值对。可以使用show variables like命令查看,也可以通过information_schema的GLOBAL_VARIABLES视图来查找。

3.1.2、参数类型

      参数文件分为两类:动态参数和静态参数。动态参数意味着你可以在Mysql实例运行中进行更改;静态参数说明在整个实例生命周期内都不得进行更改,好像是只读的。对于动态参数,又可以分为global和session关键字,表明该参数的修改是基于当前会话还是真格实例的生命周期。有些动态参数只能在会话中进行修改,如autocommit;有些参数修改完后,在整个实例生命周期中都会生效,如binlog_cache_size;而有些参数既可以在会话又可以在整个实例的生命周期内生效,如read_buffer_size。

3.2、日志文件

3.2.1、错误日志

      错误日志对Mysql的启动、运行、关闭过程进行了记录。出现Mysql不能正常启动时,第一个必须查找的文件应该就是错误日志文件。使用show variables like ‘log_error’来定位文件。

3.2.2、慢查询日志

      慢查询能为SQL语句的优化带来很好的帮助。设定一个阀值,将运行时间超过该值的所有SQL语句都记录到慢查询日志文件中。用参数long_query_time来设置。另一个参数log_queries_not_using_indexes,若运行的SQL语句没有使用索引,则这条SQL语句会被记录下来。

3.2.3、查询日志

      查询日志记录了所有对Mysql请求的信息,不论这些请求是否得到正确的执行。默认文件名为:主机名.log。

3.2.4、二进制日志

      二进制记录了对数据库执行更改的所有操作,但是不包括SELECT和SHOW操作,还包括了执行时间和更改操作时间。可用来恢复某些数据,同时也可以用来复制同步远程数据库。将binlog_format设置成row,可以支持事务隔离级别为READ COMMITTED,以获得更好的并发性。在使用MIXED格式下,mysql采用STATEMENT格式进行二进制日志文件的记录,但是有一些情况下会使用ROW格式,可能的情况如下:

1、表的存储引擎为NDB,这个时候DML操作都会以ROW格式记录。

2、使用了uuid()、user(),current_user(),found_rows(),row_count(),等不确定函数。

3、使用了insert delay语句

4、使用了用户定于的函数(UDF)

5、使用了临时表(temporary table)

注意:针对系统库mysql里面的表发生变化的处理规则如下:

1、 如果采用insert,update,delete直接操作表,则日志根据binlog_format设定的格式记录。

2、 如果使用grant,revoke,set password等DCL语句,那么无论如何都会使用SBR模式记录。

3、 blockhole引擎不支持row格式,ndb引擎不支持statement格式。

3.3、套件字文件

 Unix系统下本地连接Mysql可以采用Unix套接字方法,需要一个套接字文件,可以使用show variableslike ‘socket’查询。

3.4、pid文件和表结构定义文件

         pid文件是实例启动是记录自己进程ID号的文件,表结构定义文件是以frm为后缀名的文件,还可以用来存放视图的定义。

3.5、innodb引擎文件

3.5.1、表空间文件

         默认表空间文件为ibdata1文件innodb_data_file_path存储数据,innodb_file_per_table可以按表分别产生一个表空间.db文件,但仅存该表的数据索引和插入缓冲等信息,其他信息如undo信息,系统事务信息,double write buffer等还是存放在默认表空间(ibdata1或表空间组)里。

3.5.2、重做日志文件

      redo log是在实例或者介质失败的时候,用来保证数据完整性。每个innodb存储引擎至少有一个重做日志组,每个重做日志文件组下至少又2个重做日志文件,如默认的ib_logfile0、ib_logfile1.为了得到更高的可靠性,你可以设置多个重做镜像日志组。

      因为重做日志条目先被写到日志缓冲中,然后根据一定条件刷新到磁盘重做日志文件中。与redo log相关的就是innodb_flush_log_at_trx_commit的值,对innodb的性能影响很大。他有0,1,2三个值,0代表提交事务时,并不同步写redo log,而是等master threas每秒写。1代表commit的时候就将redo log缓存写入磁盘,2代表commit的时候将redo log缓存异步的写入磁盘。

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

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

メモ帳++7.3.1

メモ帳++7.3.1

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

SublimeText3 中国語版

SublimeText3 中国語版

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

ゼンドスタジオ 13.0.1

ゼンドスタジオ 13.0.1

強力な PHP 統合開発環境

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

SublimeText3 Mac版

SublimeText3 Mac版

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

座標系の変換を本当にマスターしましたか?自動運転と切り離せないマルチセンサーの問題 座標系の変換を本当にマスターしましたか?自動運転と切り離せないマルチセンサーの問題 Oct 12, 2023 am 11:21 AM

最初のパイロットおよび重要な記事では、主に自動運転技術で一般的に使用されるいくつかの座標系と、それらの間の相関と変換を完了し、最終的に統合環境モデルを構築する方法を紹介します。ここでの焦点は、車両からカメラの剛体への変換 (外部パラメータ)、カメラから画像への変換 (内部パラメータ)、および画像からピクセル単位への変換を理解することです。 3D から 2D への変換には、対応する歪み、変換などが発生します。要点:車両座標系とカメラ本体座標系を平面座標系とピクセル座標系に書き換える必要がある 難易度:画像の歪みを考慮する必要がある 歪み補正と歪み付加の両方を画面上で補正する2. はじめに ビジョンシステムには、ピクセル平面座標系 (u, v)、画像座標系 (x, y)、カメラ座標系 ()、世界座標系 () の合計 4 つの座標系があります。それぞれの座標系には関係性があり、

Stable Diffusion 3 の論文がついに公開され、アーキテクチャの詳細が明らかになりましたが、Sora の再現に役立つでしょうか? Stable Diffusion 3 の論文がついに公開され、アーキテクチャの詳細が明らかになりましたが、Sora の再現に役立つでしょうか? Mar 06, 2024 pm 05:34 PM

StableDiffusion3 の論文がついに登場しました!このモデルは2週間前にリリースされ、Soraと同じDiT(DiffusionTransformer)アーキテクチャを採用しており、リリースされると大きな話題を呼びました。前バージョンと比較して、StableDiffusion3で生成される画像の品質が大幅に向上し、マルチテーマプロンプトに対応したほか、テキスト書き込み効果も向上し、文字化けが発生しなくなりました。 StabilityAI は、StableDiffusion3 はパラメータ サイズが 800M から 8B までの一連のモデルであると指摘しました。このパラメーター範囲は、モデルを多くのポータブル デバイス上で直接実行できることを意味し、AI の使用を大幅に削減します。

自動運転と軌道予測についてはこの記事を読めば十分です! 自動運転と軌道予測についてはこの記事を読めば十分です! Feb 28, 2024 pm 07:20 PM

自動運転では軌道予測が重要な役割を果たしており、自動運転軌道予測とは、車両の走行過程におけるさまざまなデータを分析し、将来の車両の走行軌跡を予測することを指します。自動運転のコアモジュールとして、軌道予測の品質は下流の計画制御にとって非常に重要です。軌道予測タスクには豊富な技術スタックがあり、自動運転の動的/静的知覚、高精度地図、車線境界線、ニューラル ネットワーク アーキテクチャ (CNN&GNN&Transformer) スキルなどに精通している必要があります。始めるのは非常に困難です。多くのファンは、できるだけ早く軌道予測を始めて、落とし穴を避けたいと考えています。今日は、軌道予測に関するよくある問題と入門的な学習方法を取り上げます。関連知識の紹介 1. プレビュー用紙は整っていますか? A: まずアンケートを見てください。

DualBEV: BEVFormer および BEVDet4D を大幅に上回る、本を開いてください! DualBEV: BEVFormer および BEVDet4D を大幅に上回る、本を開いてください! Mar 21, 2024 pm 05:21 PM

この論文では、自動運転においてさまざまな視野角 (遠近法や鳥瞰図など) から物体を正確に検出するという問題、特に、特徴を遠近法 (PV) 空間から鳥瞰図 (BEV) 空間に効果的に変換する方法について検討します。 Visual Transformation (VT) モジュールを介して実装されます。既存の手法は、2D から 3D への変換と 3D から 2D への変換という 2 つの戦略に大別されます。 2D から 3D への手法は、深さの確率を予測することで高密度の 2D フィーチャを改善しますが、特に遠方の領域では、深さ予測に固有の不確実性により不正確さが生じる可能性があります。 3D から 2D への方法では通常、3D クエリを使用して 2D フィーチャをサンプリングし、Transformer を通じて 3D と 2D フィーチャ間の対応のアテンション ウェイトを学習します。これにより、計算時間と展開時間が増加します。

初のマルチビュー自動運転シーンビデオ生成世界モデル | DrivingDiffusion: BEV データとシミュレーションの新しいアイデア 初のマルチビュー自動運転シーンビデオ生成世界モデル | DrivingDiffusion: BEV データとシミュレーションの新しいアイデア Oct 23, 2023 am 11:13 AM

著者の個人的な考えの一部 自動運転の分野では、BEV ベースのサブタスク/エンドツーエンド ソリューションの開発に伴い、高品質のマルチビュー トレーニング データとそれに対応するシミュレーション シーンの構築がますます重要になってきています。現在のタスクの問題点に対応して、「高品質」は 3 つの側面に分離できます。 さまざまな次元のロングテール シナリオ: 障害物データ内の近距離車両、車両切断中の正確な進行角、車線などラインデータ 曲率の異なるカーブやランプ・合流・合流などの撮影が難しいシーン。これらは多くの場合、大量のデータ収集と複雑なデータ マイニング戦略に依存しており、コストがかかります。 3D 真の値 - 一貫性の高い画像: 現在の BEV データ取得は、センサーの設置/校正、高精度マップ、再構成アルゴリズム自体のエラーの影響を受けることがよくあります。これが私を導いた

GSLAM | 一般的な SLAM アーキテクチャとベンチマーク GSLAM | 一般的な SLAM アーキテクチャとベンチマーク Oct 20, 2023 am 11:37 AM

19 年前の論文を突然発見 GSLAM: A General SLAM Framework and Benchmark オープンソース コード: https://github.com/zdzhaoyong/GSLAM 全文に直接アクセスして、この作品の品質を感じてください ~ 1 抽象的な SLAM テクノロジー近年多くの成功を収め、多くのハイテク企業の注目を集めています。ただし、既存または新たなアルゴリズムへのインターフェイスを使用して、速度、堅牢性、移植性に関するベンチマークを効果的に実行する方法は依然として問題です。この論文では、GSLAM と呼ばれる新しい SLAM プラットフォームを提案します。これは、評価機能を提供するだけでなく、研究者が独自の SLAM システムを迅速に開発するための有用な方法を提供します。

「Minecraft」が AI の街に変わり、NPC の住人が本物の人間のようにロールプレイ 「Minecraft」が AI の街に変わり、NPC の住人が本物の人間のようにロールプレイ Jan 02, 2024 pm 06:25 PM

この四角い男性は、目の前にいる「招かれざる客」の正体について考えながら眉をひそめていることに注意してください。彼女が危険な状況にあることが判明し、これに気づくと、彼女は問題を解決するための戦略を見つけるためにすぐに頭の中で探索を始めました。最終的に、彼女は現場から逃走し、できるだけ早く助けを求め、直ちに行動を起こすことにしました。同時に、反対側の人も彼女と同じことを考えていた……『マインクラフト』では、登場人物全員が人工知能によって制御されている、そんなシーンがありました。それぞれに個性的な設定があり、例えば先ほどの女の子は17歳ながら賢くて勇敢な配達員です。彼らは記憶力と思考力を持ち、Minecraft の舞台となるこの小さな町で人間と同じように暮らしています。彼らを動かすのはまったく新しいものであり、

単なる 3D ガウス以上のもの!最先端の 3D 再構成技術の最新概要 単なる 3D ガウス以上のもの!最先端の 3D 再構成技術の最新概要 Jun 02, 2024 pm 06:57 PM

上記と著者の個人的な理解は、画像ベースの 3D 再構成は、一連の入力画像からオブジェクトまたはシーンの 3D 形状を推測することを含む困難なタスクであるということです。学習ベースの手法は、3D形状を直接推定できることから注目を集めています。このレビュー ペーパーは、これまでにない新しいビューの生成など、最先端の 3D 再構成技術に焦点を当てています。入力タイプ、モデル構造、出力表現、トレーニング戦略など、ガウス スプラッシュ メソッドの最近の開発の概要が提供されます。未解決の課題と今後の方向性についても議論します。この分野の急速な進歩と 3D 再構成手法を強化する数多くの機会を考慮すると、アルゴリズムを徹底的に調査することが重要であると思われます。したがって、この研究は、ガウス散乱の最近の進歩の包括的な概要を提供します。 (親指を上にスワイプしてください

See all articles