标签：优化 协助 逻辑型 efi mongo type 因此 最大 还需
1、MySQL的复制原理以及流程
根柢原理流程，3个线程以及之间的相关；
主：binlog线程——记载下悉数改动了数据库数据的语句，放进master上的binlog中；
?
从：io线程——在运用start slave 之后，担任从master上拉取 binlog 内容，放进 自己的relay log中；
从：sql施行线程——施行relay log中的语句；
2、MySQL中myisam与innodb的差异，至少5点
(1)、问5点不同；
1>.InnoDB支撑事物，而MyISAM不支撑事物
2>.InnoDB支撑行级锁，而MyISAM支撑表级锁
3>.InnoDB支撑MVCC, 而MyISAM不支撑
4>.InnoDB支撑外键，而MyISAM不支撑
5>.InnoDB不支撑全文索引，而MyISAM支撑。
(2)、innodb引擎的4大特性
刺进缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)
(3)、2者selectcount(*)哪个更快，为什么
myisam更快，由于myisam内部维护了一个计数器，可以直接调取。
3、MySQL中varchar与char的差异以及varchar(50)中的50代表的寓意
(1)、varchar与char的差异
char是一种固定长度的类型，varchar则是一种可变长度的类型
(2)、varchar(50)中50的寓意
最多存放50个字符，varchar(50)和(200)存储hello所占空间相同，但后者在排序时会消耗更多内存，由于order by col选用fixed_length核算col长度(memory引擎也相同)
(3)、int（20）中20的寓意
是指闪现字符的长度
但要加参数的，最大为255，比如它是记载行数的id,刺进10笔材料，它就闪现00000000001 ~~~00000000010，当字符的位数跨过11,它也只闪现11位，假定你没有加那个让它未满11位就前面加0的参数，它不会在前面加0
20标明最大闪现宽度为20，但仍占4字节存储，存储规划不变；
(4)、mysql为什么这么规划
对大多数运用没有意义，仅仅规则一些东西用来闪现字符的个数；int(1)和int(20)存储和核算均相同；
4、问了innodb的事务与日志的结束方法
(1)、有多少种日志；
过错日志：记载犯错信息，也记载一些警告信息或许正确的信息。
查询日志：记载悉数对数据库央求的信息，不管这些央求是否得到了正确的施行。
慢查询日志：设置一个阈值，将作业时间跨过该值的悉数SQL语句都记载到慢查询的日志文件中。
二进制日志：记载对数据库施行更改的悉数操作。
中继日志：中继日志也是二进制日志，用来给slave 库康复
事务日志：重做日志redo和回滚日志undo
(2)、事物的4种隔绝等级
隔绝等级
读未提交(RU)
读已提交(RC)
可重复读(RR)
串行
(3)、事务是怎样经过日志来结束的，说得越深化越好。
事务日志是经过redo和innodb的存储引擎日志缓冲（Innodb log buffer）来结束的，当开始一个事务的时分，会记载该事务的lsn(log sequence number)号; 当事务施行时，会往InnoDB存储引擎的日志的日志缓存里面刺进事务日志；当事务提交时，有必要将存储引擎的日志缓冲写入磁盘（经过innodb_flush_log_at_trx_commit来控制），也就是写数据前，需求先写日志。这种方法称为“预写日志方法”
5、MySQL binlog的几种日志录入格式以及差异
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 更多的行级锁
Row:不记载sql语句上下文相关信息，仅保存哪条记载被修改。
利益： binlog中可以不记载施行的sql语句的上下文相关的信息，仅需求记载那一条记载被修改成什么了。所以rowlevel的日志内容会非常清楚的记载下 每一行数据修改的细节。而且不会呈现某些特定情况下的存储进程，或function，以及trigger的调用和触发无法被正确复制的问题
缺陷:悉数的施行的语句当记载到日志中的时分，都将以每行记载的修改来记载，这样或许会发生许多的日志内容,比 如一条update语句，修改多条记载，则binlog中每一条修改都会有记载，这样构成binlog日志量会很大，特别是当施行alter table之类的语句的时分，由于表结构修改，每条记载都发生改动，那么该表每一条记载都会记载到日志中。
Mixedlevel: 是以上两种level的混合运用，一般的语句修改运用statment格式保存binlog，如一些函数，statement无法结束主从复制的操作，则 选用row格式保存binlog,MySQL会根据施行的每一条详细的sql语句来区别对待记载的日志方法，也就是在Statement和Row之间挑选 一种.新版本的MySQL中队row level方法也被做了优化，并不是悉数的修改都会以row level来记载，像遇到表结构改动的时分就会以statement方法来记载。至于update或许delete等修改数据的语句，仍是会记载悉数行的改动。
6、MySQL数据库cpu飙升到500%的话他怎样处理？
1、列出悉数进程 show processlist,查询悉数进程 ,多秒没有情况改动的(干掉)
2、查看超时日志或许过错日志 (做了几年开发,一般会是查询以及大批量的刺进会导致cpu与i/o上涨,当然不打扫网络情况遽然断了,导致一个央求服务器只接受到一半，比如where子句或分页子句没有发送,,当然的一次被坑阅历)
7、sql优化各种方法
(1)、explain出来的各种item的意义；
select_type
标明查询中每个select子句的类型
type
标明MySQL在表中找到所需行的方法，又称“拜访类型”
possible_keys
指出MySQL能运用哪个索引在表中找到行，查询涉及到的字段上若存在索引，则该索引将被列出，但不必定被查询运用
key
闪现MySQL在查询中实践运用的索引，若没有运用索引，闪现为NULL
key_len
标明索引中运用的字节数，可经过该列核算查询中运用的索引的长度
ref
标明上述表的联接匹配条件，即哪些列或常量被用于查找索引列上的值
Extra
包括不适合在其他列中闪现但非常重要的额定信息
(2)、profile的意义以及运用场景；
查询到 SQL 会施行多少时间, 并看出 CPU/Memory 运用量, 施跋涉程中 Systemlock, Table lock 花多少时间等等
8、备份方案，mysqldump以及xtranbackup的结束原理
(1)、备份方案；
这儿每个公司都不相同，您别说那种1小时1全备什么的就行
(2)、备份康复时间；
这儿跟机器，尤其是硬盘的速率有联络，以下罗列几个仅供参考
20G的2分钟（mysqldump）
80G的30分钟(mysqldump)
111G的30分钟（mysqldump)
288G的3小时（xtra)
3T的4小时（xtra)
逻辑导入时间一般是备份时间的5倍以上
(3)、xtrabackup结束原理
在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记载修改。当InnoDB启动时，InnoDB会查看数据文件和事务日志，并施行两个进程：它运用（前滚）现已提交的事务日志到数据文件，并将修改正但没有提交的数据进行回滚操作。
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 pool以及 local buffer；
(2)、写入参数；
innodb_flush_log_at_trx_commit
innodb_buffer_pool_size
(3)、与IO相关的参数；
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_thread_concurrency = 0
(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、你们数据库是否支撑emoji表情，假定不支撑，怎样操作？
假定是utf8字符集的话，需求晋级至utf8_mb4方可支撑
15、你是怎样维护数据库的数据字典的？
这个我们维护的方法都不同，我一般是直接在出产库进行注释，运用东西导出成excel便当流通。
16、表中有大字段X(例如：text类型)，且字段X不会常常更新，以读为为主，请问
拆带来的问题：联接消耗 + 存储拆分空间；不拆或许带来的问题：查询功用；
1、假定能忍耐拆分带来的空间问题,拆的话最好和常常要查询的表的主键在物理结构上放置在一同(分区) 次序IO,削减联接消耗,终究这是一个文本列再加上一个全文索引来尽量抵消联接消耗
2、假定能忍耐不拆分带来的查询功用丢掉的话:上面的方案在某个极致条件下肯定会呈现问题,那么不拆就是最好的挑选
17、MySQL中InnoDB引擎的行锁是经过加在什么上结束(或称结束)的？为什么是这姿态的？
InnoDB是根据索引来结束行锁
例: select * from tab_with_index where id = 1 for update;
for update 可以根据条件来结束行锁供认,而且 id 是有索引键的列,
假定 id 不是索引键那么InnoDB将结束表锁,,并发将无从谈起
18、翻开性问题：据说是腾讯的
一个6亿的表a，一个3亿的表b，经过外间tid相关，你怎样最快的查询出满足条件的第50000到第50200中的这200条数据记载。
1、假定A表TID是自增加,而且是连续的,B表的ID为索引
select * from a,b where a.tid = b.id and a.tid>500000 limit 200;
2、假定A表的TID不是连续的,那么就需求运用掩盖索引.TID要么是主键,要么是辅佐索引,B表ID也需求有索引。
select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;
19、什么是存储进程？有哪些优缺陷？
存储进程是一些预编译的SQL语句。
1、愈加直白的了解：存储进程可以说是一个记载集，它是由一些T-SQL语句组成的代码块（johsonsbaby），这些T-SQL语句代码像一个方法相同结束一些功用（对单表或多表的增修改查），然后再给这个代码块取一个姓名，在用到这个功用的时分调用他就行了。
2、存储进程是一个预编译的代码块，施行功率比较高,一个存储进程替代许多T_SQL语句 ，可以下降网络通讯量，跋涉通讯速率,可以必定程度上保证数据安全
20、索引是什么？有什么效果以及优缺陷？
1、索引是对数据库表中一或多个列的值进行排序的结构，是协助MySQL高效获取数据的数据结构
2、索引就是加快检索表中数据的方法。数据库的索引类似于书本的索引。在书本中，索引容许用户不必翻阅无缺个书就能迅速地找到所需求的信息。在数据库中，索引也容许数据库程序迅速地找到表中的数据，而不必扫描整个数据库。
MySQL数据库几个根柢的索引类型：一般索引、仅有索引、主键索引、全文索引
1、索引加快数据库的检索速度
2、索引下降了刺进、删去、修改等维护任务的速度
3、仅有索引可以保证每一行数据的仅有性
4、经过运用索引，可以在查询的进程中运用优化躲藏器，跋涉体系的功用
5、索引需求占物理和数据空间
21、什么是事务？
事务（Transaction）是并发控制的根柢单位。所谓的事务，它是一个操作序列，这些操作要么都施行，要么都不施行，它是一个不可切开的作业单位。事务是数据库维护数据一同性的单位，在每个事务结束时，都能坚持数据一同性。
22、运用索引查询必定能跋涉查询的功用吗？为什么
一般,经过索引查询数据比全表扫描要快.可是我们也有必要注意到它的价值.
1、索引需求空间来存储,也需求守时维护, 每当有记载在表中增减或索引列被修改时,索引本身也会被修改. 这意味着每条记载的INSERT,DELETE,UPDATE将为此多支付4,5 次的磁盘I/O. 由于索引需求额定的存储空间和处理,那些不必要的索引反而会使查询反响时间变慢.运用索引查询不必定能跋涉查询功用,索引规划查询(INDEX RANGE SCAN)适用于两种情况:
2、根据一个规划的检索,一般查询回来效果集小于表中记载数的30%
3、根据非仅有性索引的检索
23、简略说一说drop、delete与truncate的区
SQL中的drop、delete、truncate都标明删去，可是三者有一些不同
1、delete和truncate只删去表的数据不删去表的结构
2、速度,一般来说: drop> truncate >delete
3、delete语句是dml,这个操作会放到rollback segement中,事务提交之后才收效;
4、假定有相应的trigger,施行的时分将被触发. truncate,drop是ddl, 操作当即收效,原数据不放到rollback segment中,不能回滚. （fawdLdieseL）操作不触发trigger.
24、drop、delete与truncate别离在什么场景之下运用？
1、不再需求一张表的时分，用drop
2、想删去部分数据行时分，用delete，而且带上where子句
3、保存表而删去悉数数据的时分用truncate
25、超键、候选键、主键、外键别离是什么？
1、超键：在联络中能仅有标识元组的特收集称为联络方法的超键。一个属功用够为作为一个超键，多个特征组合在一同也可以作为一个超键。超键包括候选键和主键。
2、候选键：是最小超键，即没有冗余元素的超键。
3、主键：数据库表中对贮存数据方针予以仅有和无缺标识的数据列或特征的组合。一个数据列只能有一个主键，且主键的取值不能缺失，即不能为空值（Null）。
4、外键：在一个表中存在的另一个表的主键称此表的外键。
26、什么是视图？以及视图的运用场景有哪些？
1、视图是一种虚拟的表，具有和物理表相同的功用。可以对视图进行增，改，查，操作，妄图一般是有一个表或许多个表的行或列的子集。对视图的修改不影响根柢表。它使得我们获取数据更简略，比较多表查询。
2、只显露部分字段给拜访者，所以就建一个虚表，就是视图。
3、查询的数据来源于不同的表，而查询者期望以一同的方法查询，这样也可以建立一个视图，把多个表查询效果联合起来，查询者只需求直接从视图中获取数据，不必考虑数据来源于不同表所带来的差异
27、说一说三个范式。
榜首范式（1NF）：数据库表中的字段都是单一特征的，不可再分。这个单一特征由根柢类型构成，包括整型、实数、字符型、逻辑型、日期型等。
第二范式（2NF）：数据库表中不存在非要害字段对任一候选要害字段的部分函数依托（部分函数依托指的是存在组合要害字中的某些字段挑选非要害字段的情况），也即悉数非要害字段都完全依托于任意一组候选要害字。
第三范式（3NF）：在第二范式的基础上，数据表中假定不存在非要害字段对任一候选要害字段的传递函数依托则契合第三范式。所谓传递函数依托，指的是如 果存在"A → B → C"的挑选联络，则C传递函数依托于A。因此，满足第三范式的数据库表应该不存在如下依托联络： 要害字段 → 非要害字段 x → 非要害字段y
28、数据库的豪宕锁和绝望锁是什么？
数据库处理体系（DBMS）中的并发控制的任务是保证在多个事务一同存取数据库中同一数据时不损坏事务的隔绝性和一同性以及数据库的一同性。豪宕并发控制(豪宕锁)和绝望并发控制（绝望锁）是并发控制首要选用的技术方法。
绝望锁：假定会发生并发冲突，屏蔽悉数或许违反数据无缺性的操作
豪宕锁：假定不会发生并发冲突，只在提交操作时查看是否违反数据无缺性。
除了以上所说这些，我们还需求把握以下这些知识点【由于篇幅过长就简略的列出以下13点技术点】
1. 高功用架构专题
1.1. 分布式架构思想
1.2. Zookeeper分布式环境指挥官
1.3. Nginx高并发分流进阶实战
1.4. ActiveMq音讯中间件
1.5. RabbitMq音讯中间件
1.6. Kafka百万级吞实战
1.7. Memcached进阶实战
1.8. Redis高功用缓存数据
1.9. MongoDB进阶实战
1.10. 高功用缓存开发实战
1.11. Mysql高功用存储实战
1.12. FastDFS分布式文件存储实战
1.13. 高并发场景分布式处理方案实战
标签：优化 协助 逻辑型 efi mongo type 因此 最大 还需
原文地址：https://www.cnblogs.com/monkey7788/p/12000190.html
