<small id='OXTDij'></small> <noframes id='gm9yJ3Z'>

  • <tfoot id='qk1TofYei'></tfoot>

      <legend id='eO0pIH'><style id='NwVM0'><dir id='i97I'><q id='PzSr46N'></q></dir></style></legend>
      <i id='diOn9v'><tr id='J8nDlXr'><dt id='r6GHsmUW'><q id='H0p3'><span id='QUxsl0Y'><b id='HvkJMVt'><form id='BdMYXA'><ins id='1JFNP'></ins><ul id='oLp4DRwy'></ul><sub id='QuhwcJ'></sub></form><legend id='SymYK4'></legend><bdo id='7GAOMB'><pre id='SDTCvsE'><center id='V6Fcz147'></center></pre></bdo></b><th id='lVXb'></th></span></q></dt></tr></i><div id='PWXvMS'><tfoot id='QuJNvZya'></tfoot><dl id='q4vuGkjZQl'><fieldset id='kJKbUTrC'></fieldset></dl></div>

          <bdo id='DaGyNZwm'></bdo><ul id='lyAOb1vJM2'></ul>

          1. <li id='5klzA'></li>
            登陆

            MySQL经典面试题

            admin 2019-11-06 250人围观 ,发现0个评论

            作者:百衲本

            cnblogs.com/panwenbin-logs/p/8366940.html

            1、MySQL的仿制原理以及流程

            (1)、仿制根本原理流程

            1. 主:binlog线程——记载下一切改动了数据库数据的句子,放进master上的binlog中;

            2. 从:io线程——在运用start slave 之后,担任从master上拉取 binlog 内容,放进 自己的relay log中;

            3. 从:sql履行线程——履行relay log中的句子;

            (2)、MySQL仿制的线程有几个及之间的相关

            MySQL 的仿制是依据如下 3 个线程的交互( 多线程仿制里边应该是 4 类线程):

            1. Master 上面的 binlog dump 线程,该线程担任将 master 的 binlog event 传到slave;

            2. Slave 上面的 IO 线程,该线程担任接纳 Master 传过来的 binlog,并写入 relay log;

            3. Slave 上面的 SQL 线程,该线程担任读取 relay log 并履行;

            4. 假如是多线程仿制,不管是 5.6 库等级的假多线程仍是 MariaDB 或许 5.7 的真实的多线程仿制, SQL 线程只做 coordinator,只担任把 relay log 中的 binlog读出来然后交给 worker 线程, woker 线程担任详细 binlog event 的履行;

            (3)、MySQL怎样确保仿制进程中数据一致性及削减数据同步延时

            一致性首要有以下几个方面:

            1.在 MySQL5.5 以及之前, slave 的 SQL 石嘴山天气线程履行的 relay log 的方位只能保存在文件( relay-log.info)里边,而且该文件默许每履行 10000 次业务做一次同步到磁盘, 这意味着 slave 意外 crash 重启时, SQL 线程履行到的方位和数据库的数据是不一致的,将导致仿制报错,假如不重搭仿制,则有或许会

            导致数据不一致。MySQL 5.6 引进参数 relay_log_info_repository,将该参数设置为 TABLE 时, MySQL 将 SQL 线程履行到的方位存到mysql.slave_relay_log_info 表,这样更新该表的方位和 SQL 线程履行的用户业务绑定成一个业务,这样 slave 意外宕机后, slave 经过 innodb 的溃散

            康复能够把 SQL 线程履行到的方位和用户业务康复到一致性的状况。

            2. MySQL 5.6 引进 GTID 仿制,每个 GTID 对应的业务在每个实例上面最多履行一次, 这极大地进步了仿制的数据一致性;

            3. MySQL 5.5 引进半同步仿制, 用户装置半同步仿制插件而且敞开参数后,设置超时时刻,可确保在超时时刻内假如 binlog 不传到 slave 上面,那么用户提交业务时不会回来,直到超时后切成异步仿制,可是假如切成异步之前用户线程提交时在 master 上面等候的时分,业务现已提交,该业务对 master

            上面的其他 session 是可见的,假如这时 master 宕机,那么到 slave 上面该业务又不行见了,该问题直到 5.7 才处理;

            4. MySQL 5.7 引进无损半同步仿制,引进参 rpl_semi_sync_master_wait_point,该参数默许为 after_sync,指的是在切成半同步之前,业务不提交,而是接纳到 slave 的 ACK 承认之后才提交该业务,从此,仿制真实能够做到无损的了。

            5.能够再说一下 5.7 的无损仿制状况下, master 意外宕机,重启后发现有 binlog没传到 slave 上面,这部分 binlog 怎样办???分 2 种状况评论, 1 宕机时现已切成异步了, 2 是宕机时还没切成异步???这个怎样判别宕机时有没有切成异步呢???别离怎样处理???

            延时性:

            5.5 是单线程仿制, 5.6 是多库仿制(关于单库或许单表的并发操作是没用的), 5.7 是真实意义的多线程仿制,它的原理是依据 group commit, 只需

            master 上面的业务是 group commit 的,那 slave 上面也能够经过多个 worker线程去并发履行。和 MairaDB10.0.0.5 引进多线程仿制的原理根本相同。

            (4)、作业遇到的仿制 bug 的处理方法

            5.6 的多库仿制有时分自己会中止,咱们写了一个脚本从头 start slave;待弥补…

            2、MySQL中myisam与innodb的差异,至少5点

            (1)、问5点不同

            1.InnoDB支撑事物,而MyISAM不支撑事物

            2.InnoDB支撑行级锁,而MyISAM支撑表级锁

            3.InnoDB支撑MVCC, 而MyISAM不支撑

            4.InnoDB支撑外键,而MyISAM不支撑

            5.InnoDB不支撑全文索引,而MyISAM支撑。

            6.InnoDB不能经过直接仿制表文件的方法仿制表到其他一台机器, myisam 支撑

            7.InnoDB表支撑多种行格局, myisam 不支撑

            8.InnoDB是索引安排表, myisam 是堆表

            (2)、innodb引擎的4大特性

            1.刺进缓冲(insert buffer)

            2.二次写(double write)

            3.自适应哈希索引(ahi)

            4.预读(read ahead)

            (3)、各种不同 mysql 版其他Innodb的改善

            MySQL5.6 下 Innodb 引擎的首要改善:

            (1) online DDL

            (2) memcached NoSQL 接口

            (3) transportable tablespace( alter table discard/import tablespace)

            (4) MySQL 正常封闭时,能够 dump 出 buffer pool 的( space, page_no),重启时 reload,加速预热速度

            (5)索引和表的核算信息耐久化到 mysql.innodb_table_stats 和mysql.innodb_index_stats,可提供安稳的履行计划

            (6)Compressed row format 支撑紧缩表

            MySQL 5.7 innodb 引擎首要改善

            (1) 修正 varchar 字段长度有时能够运用 online DDL

            (2) Buffer pool 支撑在线改动巨细

            (3) Buffer pool 支撑导出部分份额

            (4) 支撑新建 innodb tablespace,并能够在其间创立多张表

            (5) 磁盘暂时表选用 innodb 存储,而且存储在 innodb temp tablespace 里边,从前是 myisam 存储

            (6) 通明表空间紧缩功用

            (4)、2者select count(*)哪个更快,为什么

            myisam更快,由于myisam内部保护了一个计数器,能够直接调取。

            (5)、2 者的索引的完结方法

            都是 B+树索引, Innodb 是索引安排表, myisam 是堆表, 索引安排表和堆表的差异要了解

            3、MySQL中varchar与char的差异以及varchar(50)中的50代表的寓意

            (1)、varchar与char的差异

            在单字节字符集下, char(N) 在内部存储的时分总是定长, 而且没有变长字段长度列表中。在多字节字符集下面, char(N)假如存储的字节数超越 N,那么 char(N)将和 varchar(N)没有差异。在多字节字符集下面,假如存

            储的字节数少于 N,那么存储 N 个字节,后边补空格,补到 N 字节长度。都存储变长的数据和变长字段长度列表。varchar(N)不管是什么字节字符集,都是变长的,即都存储变长数据和变长字段长度列表。

            (2)、varchar(50)中50的寓意

            最多寄存50个字符,varchar(50)和(200)存储hello所占空间相同,但后者在排序时会耗费更多内存,由于order by col选用fixed_length核算col长度(memory引擎也相同)。在前期 MySQL 版别中, 50 代表字节数,现在代表字符数。

            (3)、int(20)中20的寓意

            是指显现字符的长度

            不影响内部存储,仅仅影响带 zerofill 界说的 int 时,前面补多少个 0,易于报表展现

            (4)、mysql为什么这么规划

            对大多数运用没有意义,仅仅规则一些东西用来显现字符的个数;int(1)和int(20)存储和核算均相同;

            4、innodb的业务与日志的完结方法

            (1)、有多少种日志

            redo和undo

            (2)、日志的寄存方法

            redo:在页修正的时分,先写到 redo log buffer 里边, 然后写到 redo log 的文件体系缓存里边(fwrite),然后再同步到磁盘文件( fsync)。

            Undo:在 MySQL5.5 之前, undo 只能寄存在 ibdata*文件里边, 5.6 之后,能够经过设置 innodb_undo_tablespaces 参数把 undo log 寄存在 ibdata*之外。

            (3)、业务是怎样经过日志来完结的,说得越深化越好

            根本流程如下:

            由于业务在修正页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修正数据页,再记数据页修正的 redo。Redo(里边包含 undo 的修正) 必定要比数据页先耐久化到磁盘。当业务需求回滚时,由于有 undo,能够把数据页回滚到前镜像的

            状况,溃散康复时,假如 redo log 中业务没有对应的 commit 记载,那么需求用 undo把该业务的修正回滚到业务开端之前。假如有 commit 记载,就用 redo 前滚到该业务完结时并提交掉。

            5、MySQL binlog的几种日志录入格局以及差异

            (1)、 各种日志格局的寓意

            1.Statement:每一条会修正数据的sql都会记载在binlog中。

            长处:不需求记载每一行的改动,削减了binlog日志量,节约了IO,进步功用。(比较row能节约多少功用 与日志量,这个取决于运用的SQL状况,正常同一条记载修正或许刺进row格局所发作的日志量还小于Statement发作的日志量,

            可是考虑到假如带条 件的update操作,以及整表删去,alter表等操作,ROW格局会发作许多日志,因而在考虑是否运用ROW格局日志时应该跟据运用的实践状况,其所 发作的日志量会添加多少,以及带来的IO功用问题。)

            缺点:由于记载的仅仅履行句子,为了这些句子能在slave上正确运转,因而还有必要记载每条句子在履行的时分的 一些相关信息,以确保一切句子能在slave得到和在master端履行时分相同 的成果。其他mysql 的仿制,

            像一些特定函数功用,slave可与master上要保持一致会有许多相关问题(如sleep()函数, last_insert_id(),以及user-defined functions(udf)会呈现问题).

            运用以下函数的句子也无法被仿制:

            * LOAD_FILE()

            * UUID()

            * USER()

            * FOUND_ROWS()

            * SYSDATE() (除非发动时启用了 --sysdate-is-now 选项)

            一同在INSERT ...SELECT 会发作比 RBR 更多的行级锁

            2.Row:不记载sql句子上下文相关信息,仅保存哪条记载被修正。

            长处:binlog中能够不记载履行的sql句子的上下文相关的信息,仅需求记载那一条记载被修正成什么了。所以rowlevel的日志内容会十分清楚的记载下 每一行数据修正的细节。而且不会呈现某些特定状况下的存储进程,或function,以及trigger的调用和触发无法被正确仿制的问题

            缺点:一切的履行的句子当记载到日志中的时分,都将以每行记载的修正来记载,这样或许会发作许多的日志内容,比 如一条update句子,修正多条记载,则binlog中每一条修正都会有记载,这样形成binlog日志量会很大,特别是当履行alter table之类的句子的时分,

            由于表结构修正,每条记载都发作改动,那么该表每一条记载都会记载到日志中。

            3.Mixedlevel: 是以上两种level的混合运用,一般的句子修正运用statment格局保存binlog,如一些函数,statement无法完结主从仿制的操作,则 选用row格局保存binlog,MySQL会依据履行的每一条详细的sql句子来差异对待记载的日志方法,

            也便是在Statement和Row之间挑选 一种.新版其他MySQL中队row level形式也被做了优化,并不是一切的修正都会以row level来记载,像遇到表结构改变的时分就会以statement形式来记载。至于update或许delete等修正数据的句子,仍是会记载一切行的改变。

            (2)、适用场景

            在一条 SQL 操作了多行数据时, statement 更节约空间, row 更占用空间。可是 row形式更牢靠。

            (3)、结合第一个问题,每一种日志格局在仿制中的好MySQL经典面试题坏

            Statement 或许占用空间会相对小一些,传送到 slave 的时刻或许也短,可是没有 row形式的牢靠。Row 形式在操作多行数据时更占用空间, 可是牢靠。

            6、下MySQL数据库cpu飙升到500%的话他怎样处理?

            当 cpu 飙升到 500%时,先用操作体系指令 top 指令调查是不是 mysqld 占用导致的,假如不是,找出占用高的进程,并进行相关处理。假如是 mysqld 形成的, show processlist,看看里边跑的 session 状况,是不是有耗费资源的 sql 在运转。找出耗费高的 sql,

            看看履行计划是否精确, index 是否缺失,或许实在是数据量太大形成。一般来说,必定要 kill 掉这些线程(一同调查 cpu 运用率是否下降),等进行相应的调整(比方说加索引、改 sql、改内存参数)之后,再从头跑这些 SQL。也有或许是每个 sql 耗费资源并不多,可是突然之间,

            有许多的 session 连进来导致 cpu 飙升,这种状况就需求跟运用一同来剖析为何衔接数会激增,再做出相应的调整,比方说约束衔接数等

            7、sql优化

            (1)、explain出来的各种item的意义

            id:每个被独立履行的操作的标志,表明目标被操作的次序。一般来说, id 值大,先被履行;假如 id 值相同,则次序从上到下。

            select_type:查询中每个 select 子句的类型。

            table:姓名,被操作的目标称号,一般的表名(或许别号),可是也有其他格局。

            partitions:匹配的分区信息。

            type:join 类型。

            possible_keys:列出或许会用到的索引。

            key:实践用到的索引。

            key_len:用到的索引键的均匀长度,单位为字节。

            ref:表明本行被操作的目标的参照目标,或许是一个常量用 const 表明,也或许是其他表的

            key 指向的目标,比方说驱动表的衔接列。

            rows:估量每次需求扫描的行数。

            filtered:rows*filtered/100 表明该过程最终得到的行数(估量值)。

            extra:重要的弥补信息。

            (2)、profile的意义以及运用场景

            Profile 用来剖析 sql 功用的耗费散布状况。当用 explain 无法处理慢 SQL 的时分,需求用profile 来对 sql 进行更详尽的剖析,找出 sql 所花的时刻大部分耗费在哪个部分,承认 sql的功用瓶颈。

            (3)、explain 中的索引问题

            Explain 成果中,一般来说,要看到尽量用 index(type 为 const、 ref 等, key 列有值),防止运用全表扫描(type 显式为 ALL)。比方说有 where 条件且挑选性不错的列,需求树立索引。

            被驱动表的衔接列,也需求树立索引。被驱动表的衔接列也或许会跟 where 条件列一同树立联合索引。当有排序或许 group by 的需求时,也能够考虑树立索引来到达直接排序和汇总的需求。

            8、备份计划,mysqldump以及xtranbackup的完结原理

            (1)、备份计划

            视库的巨细来定,一般来说 100G 内的库,能够考虑运用 mysqldump 来做,由于 mysqldump愈加轻盈灵敏,备份时刻选在业务低峰期,能够每天进行都进行全量备份(mysqldump 备份

            出来的文件比较小,紧缩之后更小)。100G 以上的库,能够考虑用 xtranbackup 来做,备份速度显着要比 mysqldump 要快。一般是挑选一周一个全备,其他每天进行增量备份,备份时刻为业务低峰期。

            (2)、备份康复时刻

            物理备份康复快,逻辑备份康复慢

            这儿跟机器,尤其是硬盘的速率有联系,以下罗列几个仅供参阅

            20G的2分钟(mysqldump)

            80G的30分钟(mysqldump)

            111G的30分钟(mysqldump)

            288G的3小时(xtra)

            3T的4小时(xtra)

            逻辑导入时刻一般是备份时刻的5倍以上

            (3)、备份康复失利怎样处理

            首要在康复之前就应该做足预备作业,防止康复的时分犯错。比方说备份之后的有效性查看、权限查看、空间查看等。假如假如报错,再依据报错的提示来进行相应的调整。

            (4)、mysqldump和xtrabackup完结原理

            mysqldump

            mysqldump 归于逻辑备份。参加--single-transaction 选项能够进行一致性备份。后台进程会先设置 session 的业务阻隔等级为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ),

            之后显式敞开一个业务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */),这样就确保了该业务里读到的数据都是业务业务时分的快照。之后再把表的数据读取出来。假如加上--master-data=1 的话,在刚开端的时分还会加一个数据库的读锁

            (FLUSH TABLES WITH READ LOCK),等敞开业务后,再记载下数据库此刻 binlog 的方位(showmaster status),立刻解锁,再读取表的数据。等一切的数据都现已导完,就能够完毕业务

            Xtrabackup:

            xtrabackup 归于物理备份,直接仿制表空间文件,一同不断扫描发作的 redo 日志并保存下来。最终完结 innodb 的备份后,会做一个 flush engine logs 的操作(老版别在有 bug,在5.6 上不做此操作会丢数据),确保一切的 redo log 都现已落盘(涉及到业务的两阶段提交

            概念,由于 xtrabackup 并不仿制 binlog,所以有必要确保一切的 redo log 都落盘,不然或许会丢最终一组提交业务的数据)。这个时刻点便是 innodb 完结备份的时刻点,数据文件尽管不是一致性的,可是有这段时刻的 redo 就能够让数据文件到达一致性(康复的时分做的事

            情)。然后还需求 flush tables with read lock,把 myisam 等其他引擎的表给备份出来,备份完后解锁。这样就做到了完美的热备。

            9、mysqldump中备份出来的sql,假如我想sql文件中,一行只需一个insert....value()的话,怎样办?假如备份需求带上master的仿制点信息怎样办?



            --skip-extended-insert
            [root@helei-zhuanshu ~]# mysqldump -uroot -p helei --skip-extended-insert
            Enter password:
            KEY `idx_c1` (`c1`),
            KEY `idx_c2` (`c2`)
            ) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=latin1;
            /*!40101 SET character_set_client = @saved_cs_client */;
            --
            -- Dumping data for table `helei`
            --
            LOCK TABLES `helei` WRITE;
            /*!40000 ALTER TABLE `helei` DISABLE KEYS */;
            INSERT INTO `helei` VALUES (1,32,37,38,'2016-10-18 06:19:24','susususususususususususu');
            INSERT INTO `helei` VALUES (2,37,46,21,'2016-10-18 06:19:24','susususususu');
            INSERT INTO `helei` VALUES (3,21,5,14,'2016-10-18 06:19:24','susu');


            10、500台db,在最快时刻之内重启

            能够运用批量 ssh 东西 pssh 来对需求重启的机器履行重启指令。也能够运用 salt(条件是客户端有装置 salt)或许 ansible( ansible 只需求 ssh 免登通了就行)等多线程东西一同操作多台服务器

            11、innodb的读写参数优化

            (1)、读取参数


            global buffer 以及 local buffer;
            Global buffer:
            Innodb_buffer_pool_size
            innodb_log_buffer_size
            innodb_additional_mem_pool_size
            local buffer(下面的都是 server 层的 session 变量,不是 innodb 的):
            Read_buffer_size
            Join_buffer_size
            Sort_buffer_size
            Key_buffer_size
            Binlog_cache_size


            (2)、写入参数


            innodb_flush_log_at_trx_commit
            innodb_buffer_pool_size
            insert_buffer_size
            innodb_double_write
            innodb_write_io_thread
            innodb_flush_method


            (3)、与IO相关的参数


            innodb_write_io_threads = 8
            innodb_read_io_threads = 8
            innodb_thread_concurrency = 0
            Sync_binlog
            Innodb_flush_log_at_trx_commit
            Innodb_lru_scan_depth
            Innodb_io_capacity
            Innodb_io_capacity_max
            innodb_log_buffer_size
            innodb_max_dirty_pages_pct


            (4)、缓存参数以及缓存的适用场景

            query cache/query_cache_type

            并不是一切表都合适运用query cache。形成query cache失效的原因首要是相应的table发作了改变

            第一个:读操作多的话看看份额,简略来说,假如是用户清单表,或许说是数据份额比较固定,比方说产品列表,是能够翻开的,条件是这些库比较会集,数据库中的实务比较小。

            第二个:咱们“行骗”的时分,比方说咱们竞标的时分压测,把query cache翻开,仍是能收到qps激增的作用,当然条件示前端的衔接池什么的都装备相同。大部分状况下假如写入的居多,访问量并不多,那么就不要翻开,例如交际网站的,10%的人发作内容,其他的90%都在消费,翻开仍是作用很好的,可是你假如是qq音讯,或许谈天,那就很要命。

            第三个:小网站或许没有高并发的无所谓,高并发下,会看到 许多 qcache 锁 等候,所以一般高并发下,不主张翻开query cache

            12、你是怎样监控你们的数据库的?你们的慢日志都是怎样查询的?


            监控的东西有许多,例如zabbix,lepus,我这儿用的是lepus

            13、你是否做过主从一致性校验,假如有,怎样做的,假如没有,你计划怎样做?


            主从一致性校验有多种东西 例如checksum、mysqldiff、pt-table-checksum等

            14、表中有大字段X(例如:text类型),且字段X不会常常更新,以读为为主,请问您是挑选拆成子表,仍是持续放一同?写出您这样挑选的理由


            答:拆带来的问题:衔接耗费 + 存储拆分空间;不拆或许带来的问题:查询功用;

            假如能忍受拆分带来的空间问题,拆的话最好和常常要查询的表的主键在物理结构上放置在一同(分区) 次序IO,削减衔接耗费,最终这是一个文本列再加上一个全文索引来尽量抵消衔接耗费

            假如能忍受不拆分带来的查询功用丢失的话:上面的计划在某个极致条件下必定会呈现问题,那么不拆便是最好的挑选

            15、MySQL中InnoDB引擎的行锁是经过加在什么上完结(或称完结)的?为什么是这姿态的?


            答:InnoDB是依据索引来完结行锁

            例: select * from tab_with_index where id = 1 for update;

            for update 能够依据条件来完结行锁确定,而且 id 是有索引键的列,

            假如 id 不是索引键那么InnoDB将完结表锁,,并发将无从谈起

            16、怎样从mysqldump发作的全库备份中只康复某一个库、某一张表?


            全库备份
            [root@HE1 ~]# mysqldump -uroot -p --single-transaction -A --master-data=2 >dump.sql
            只复原erp库的内容
            [root@HE1 ~]# mysql -uroot -pMANAGER erp --one-database
            能够看出这儿首要用到的参数是--one-database简写-o的参数,极大方便了咱们的康复灵敏性
            那么怎样从全库备份中抽取某张表呢,全库康复,再康复某张表小库还能够,大库就很麻烦了,那咱们能够运用正则表达式来进行快速抽取,详细完结方法如下:

            从全库备份中抽取出t表的表结构
            [root@HE1 ~]# sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE `t`/!d;q' dump.sql

            DROP TABLE IF EXISTS`t`;
            /*!40101 SET@saved_cs_client =@@character_set_client */;
            /*!40101 SETcharacter_set_client = utf8 */;
            CREATE TABLE `t` (
            `id` int(10) NOT NULL AUTO_INCREMENT,
            `age` tMySQL经典面试题inyint(4) NOT NULL DEFAULT '0',
            `name` varchar(30) NOT NULL DEFAULT '',
            PRIMARY KEY (`id`)
            ) ENGINE=InnoDBAUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
            /*!40101 SETcharacter_set_client = @saved_cs_client */;

            从全库备份中抽取出t表的内容
            [root@HE1 ~]# grep'INSERT INTO `t`' dump.sql
            INSERT INTO `t`VALUES (0,0,''),(1,0,'aa'),(2,0,'bbb'),(3,25,'helei');

            17、在当时的作业中,你碰到到的最大的 mysql db 问题以及怎样处理的?

            能够挑选一个处理过的比较扎手的事例,或许挑选一个教师在课程上讲过的死锁的事例;没有及时 Purge + insert 仅有索引形成的死锁:详细事例能够参阅学委笔记。

            18、请简练地描绘下 MySQL 中 InnoDB 支撑的四种业务阻隔等级称号,以及逐级之间的差异?

            (1)、事物的4种阻隔等级

            读未提交(read uncommitted)

            读已提交(read committed)

            可重复读(repeatable read)

            串行(serializable)

            (2)、不同等级的现象

            Read Uncommitted:能够读取其他 session 未提交的脏数据。

            Read Committed:答应不行重复读取,但不答应脏读取。提交后,其他会话能够看到提交的数据。

            Repeatable Read: 制止不行重复读取和脏读取、以及幻读(innodb 独有)。

            Serializable: 业务只能一个接着一个地履行,但不能并发履行。业务阻隔等级最高。

            不同的阻隔等级有不同的现象,并有不同的确定/并发机制,阻隔等级越高,数据库的并发性就越差。


            面试中其他的问题:

            1、2 年 MySQL DBA 经历

            其间许多有水分,一看到简历毛遂自荐,说公司项目的时分,会写上 linux 体系保护,mssql server 项目,或许 oracle data gard 项目,一般假如有这些的话,作业在 3 年到 4年的话,他的 2 年 MySQL DBA 办理经历,是有很大的水分的。刚开端我跟领导说,这些

            不必去面试了,必定 mysql dba 经历缺乏,领导说先面面看看,所以我就面了,成果许多人卡在根底知识这一环节之上,比方:

            (1)有的卡在仿制原理之上

            (2)有的卡在 binlog 的日志格局的品种和别离

            (3)有的卡在 innodb 业务与日志的完结上。

            (4)有的卡在 innodb 与 myisam 的索引完结方法的了解上面。

            .........

            个人觉得假如有过真实的 2 年 mysql 专职 dba 经历,那么必定会在 mysql 的根本原理上有所研讨,由于许多问题都不得不让你去细心研讨各种细节,而自 己研讨过的细节必定会回忆深入,他人问起必定会说的头头是道,最少一些最根本的要害参数比方

            Seconds_Behind_Master 为 60 这个值 60 的精确寓意,面试了 10+的 mysql dba,没有一个说的精确,有的说不知道忘记了,有的说是差了 60 秒,有的说是与主上履行时刻拖延了 60 秒。

            2 、关于简历中写有了解 mysql 高可用计划

            我一般先问他现在办理的数据库架构是什么,假如他只说出了主从,而没有说任何 ha的计划,那么我就能够判别出他没有实践的 ha 经历。不过这时分也不能便是 判定他不理解mysql 高可用,也许是没有实践机会去运用,那么我就要问 mmm 以及 mha 以及mm+keepalived 等的原理

            完结方法以及它们之间的优 势和缺乏了,一般这种状况下,能说出这个的根本没有。mmm 那东西如同不靠谱,听说不安稳,可是有人在用的,我只在虚拟机上面用过,和mysql-router 比较像,都是指定可写的机器和只读机器。MHA 的话一句话说不完,能够翻翻学委的笔记

            3 、关于简历中写有批量 MySQL 数据库服务器的办理经历

            这个假如他说有的话,我会先问他们现在实践线上的 mysql 数据库数量有多少,分多少个节点组,最终问这些节点组上面的 slow log 是怎样组合在一同来核算剖析的。假如这些他都答对了,那么我还有一问,便是现在手上有 600 台数据库,新来的机器, Mysql 都

            装置好了,那么你如 安在最快的时刻里边把这 600 台 mysql 数据库的 mysqld 服务发动起来。这个要点在于最快的时刻,而能精确答复出明晰思路的只需 2 个人。slow log 剖析:能够经过一个办理服务器守时去各台 MySQL 服务器上面 mv 而且 cp slowlog,

            然后剖析入库,页面展现。最快的时刻里边发动 600 台服务器:必定是多线程。能够用 pssh, ansible 等多线程批量办理服务器的东西

            4 、关于有丰厚的 SQL 优化的经历

            首要问 mysql 中 sql 优化的思路,假如能预备说出来, ok,那么我就开端问 explain的各种参数了,要点是 select_type, type, possible_key, ref,rows,extra 等参数的各种

            值的意义,假如他都答复正确了,那么我再问 file sort 的意义以及什么时分会呈现这个剖析成果,假如这儿他也答复对了,那么我就预备问 profile 剖析了,假如这儿他也答对了,那么我就会再问一个问 题,

            那是从前 tx 问我的让我抑郁不已的问题,一个 6 亿的表 a,一个 3 亿的表 b,经过外间 tid 相关,你怎样最快的查询出满意条件的第 50000 到第 50200中的这 200 条数据记载。

            Explain 在上面的标题中有了,这儿就不说了。怎样最快的查询出满意条件的第 50000 到第 50200 中的这 200 条数据记载?这个我想不出来!

            关于 explain 的各种参数,请参阅:http://blog.csdn.net/mchdba/article/details/9190771


            5、关于有丰厚的数据库规划经历

            这个关于数据库规划我真的没有太多的经历,我也就只能问问最根底的, mysql 中varchar(60) 60 是啥意义, int(30)中 30 是啥意义?假如他都答复对了,那么我就问 mysql中为什么要这么规划呢?

            假如他还答复对了,我就持续问 int(20)存储的数字的上限和下限是多少?这个问题莫非了悉数的 mysql dba 的应聘者,不得不敬服提出这个问题的金总的睿智啊,由于这个问题答复正确了,

            那么他的确仔仔细细地研讨了 mysql 的规划中关于字段类型的细节。至 于丰厚的规划数据库的经历,不必着急,这不我上面还有愈加凶猛的 dba吗,他会搞理解的,那就跟我无关了。

            varchar(60)MySQL经典面试题的 60 表明最多能够存储 60 个字符。int(30)的 30 表明客户端显现这个字段的宽度。

            为何这么规划?说不清楚,请咱们弥补 。int(20)的上限为 2147483647(signed)或许4294967295(unsigned)。

            6 、关于 mysql 参数优化的经历

            首要问他它们线上 mysql 数据库是怎样装置的,假如说是 rpm 装置的,那么我就直接问调优参数了,假如是源码装置的,那么我就要问编译中的一些参数了,比方 my.cnf 以及存储引擎以及字符类型等等。然后从以下几个方面问起:

            (1) mysql 有哪些 global 内存参数,有哪些 local 内存参数。

            Global:

            innodb_buffer_pool_size/innodb_additional_mem_pool_size/innodb_log_buffer_size/key_buffer_size/query_cache_size/table_open_cache/table_definition_cache/thread_cache_size

            Local:

            read_buffer_size/read_rnd_buffer_size/sort_buffer_size/join_buffer_size/binlog_cache_size/tmp_table_size/thread_stack/bulk_insert_buffer_size

            (2) mysql 的写入参数需求调整哪些?重要的几个写参数的几个值得意义以及适用场景,

            比方 innodb_flush_log_at_trx_commit 等。(求弥补)

            sync_binlog 设置为 1,确保 binlog 的安全性。

            innodb_flush_log_at_trx_commit:

            0:业务提交时不将 redo log buffer 写入磁盘(仅每秒进行 master thread 改写,安全

            性最差,功用最好)

            1:业务提交时将 redo log buffer 写入磁盘(安全性最好,功用最差, 引荐出产运用)

            2:业务提交时仅将 redo log buffer 写入操作体系缓存(安全性和功用都居中,当 mysql宕机可是操作体系不宕机则不丢数据,假如操作体系宕机,最多丢一秒数据)

            innodb_io_capacity/innodb_io_capacity_max:看磁盘的功用来定。假如是 HDD 能够设置为 200-几百不等。假如是 SSD,引荐为 4000 左右。innodb_io_capacity_max 更大一些。

            innodb_flush_method 设置为 O_DIRECT。

            (3) 读取的话,那几个大局的 pool 的值的设置,以及几个 local 的 buffer 的设置。

            Global:

            innodb_buffer_pool_size:设置为可用内存的 50%-60%左右,假如不行,再渐渐上调。

            innodb_additional_mem_pool_size:选用默许值 8M 即可。

            innodb_log_buffer_size:默许值 8M 即可。

            key_buffer_size:myisam 表需求的 buffer size,挑选根本都用 innodb,所以选用默许的 8M 即可。

            Local:

            join_buffer_size:当 sql 有 BNL 和 BKA 的时分,需求用的 buffer_size(plain index

            scans, range index scans 的时分或许也会用到)。默许为 256k,主张设置为 16M-32M。

            read_rnd_buffer_size:当运用 mrr 时,用到的 buffer。默许为 256k,主张设置为16-32M。

            read_buffer_size:当次序扫描一个 myisam 表,需求用到这个 buffer。或许用来决议memory table 的巨细。或许一切的 engine 类型做如下操作:order by 的时分用 temporaryfile、 SELECT INTO … OUTFILE 'filename' 、 For caching results of nested queries。默许为 128K,主张为 16M。

            sort_buffer_size:sql 句子用来进行 sort 操作(order by,group by)的 buffer。假如 buffer 不行,则需求树立 temporary file。假如在 show global status 中发现有许多的 Sort_merge_passes 值,则需求考虑调大 sort_buffer_size。默许为 256k,主张设置为 16-32M。

            binlog_cache_size:表明每个 session 中寄存 transaction 的 binlog 的 cache size。默许 32K。一般运用默许值即可。假如有大业务,能够考虑调大。

            thread_stack:每个进程都需求有,默许为 256K,运用默许值即可。

            (4) 还有便是闻名的 query cache 了,以及 query cache 的适用场景了,这儿有一个圈套

            便是高并发的状况下,比方双十一的时分, query cache 开仍是不开,开了怎样确保高并发,不开又有何其他考虑?主张封闭,上了功用反而更差。

            7、关于了解 mysql 的锁机制

            gap 锁, next-key 锁,以及 innodb 的行锁是怎样完结的,以及 myisam 的锁是怎样完结的等

            Innodb 的锁的策略为 next-key 锁,即 record lock+gap lock。是经过在 index 上加 lock 完结的,假如 index 为 unique index,则降级为 record lock,假如是一般 index,则为 next-key lock,假如没有 index,则直接锁住全表。myisam 直接运用全表扫描。

            8、 关于了解 mysql 集群的

            我就问了 ndbd 的节点的发动先后次序,再问装备参数中的内存装备几个重要的参数,再问 sql 节点中履行一个 join 表的 select 句子的完结流程是怎样走的?ok,能答复的也只需一个。

            关于 mysql 集群入门材料,请参阅:http://write.blog.csdn.net/postlist/1583151/all

            9、 关于有丰厚的备份经历的

            就问 mysqldump 中备份出来的 sql,假如我想 sql 文件中,一行只需一个 insert .... value()的话,怎样办?假如备份需求带上 master 的仿制点信息怎样办?或许 xtrabackup 中怎样

            做到实时在线备份的?以及 xtrabackup 是怎样做到带上 master 的仿制点的信息的?当时 xtrabackup 做增量备份的时分有何缺点?能悉数答复出来的没有一个,不过没有联系,只需答复出 mysqldump 或许xtrabackup 其间一个的也能够。

            1). --skip-extended-insert

            2). --master-date=1

            3). 由于 xtrabackup 是多线程,一个线程不停地在仿制新发作的 redo 文件,其他的线程去备份数据库,当一切表空间备份完结的时分,它会履行 flush table with read lock 操作

            锁住一切表,然后履行 show master status; 接着履行 flush engine logs; 最终解锁表。履行 show master status; 时就能获取到 mster 的仿制点信息,履行 flush engine logs 强制把redo 文件改写到磁盘。

            4). xtrabackup 增量备份的缺点不了解,在线上用 xtrabackup 备份没有发现什么缺点。

            10 、关于有丰厚的线上康复经历的

            就问你现在线上数据量有多大,假如是 100G,你用 mysqldump 出来要多久,然后 mysql进去又要多久,假如互联网不答应延时的话,你又怎样做到 康复单张表的时分确保 nagios不报警。假如有人说 mysqldump 出来 1 个小时就 ok 了,那么我就要问问他 db 服务器是

            啥装备了,假如他说 mysql 进去 50 分钟搞定了,那么我也要问问他 db 机器啥装备了,假如是一般的吊丝 pc server,那么真实性,咱们懂得。然后假如你用 xtrabackup 备份要多久,康复要多久,咱们都知道 copy-back 这一步要好久,那么你有没有方法对这一块优化。


            假如本文对您有协助,请您帮助重视并转发,您的重视是咱们最大的动力!

            请关注微信公众号
            微信二维码
            不容错过
            Powered By Z-BlogPHP