2 假装自己不胖

尚未进行身份认证

我要认证

暂无相关简介

等级
TA的排名 6w+

innodb和 memory的区别

innodb和 memory的区别InnoDB 表的数据总是有序存放的,而内存表的数据就是按照写入顺序存放的;当数据文件有空洞的时候,InnoDB 表在插入新数据的时候,为了保证数据有序性,只能在固定的位置写入新值,而内存表找到空位就可以插入新值;数据位置发生变化的时候,InnoDB 表只需要修改主键索引,而内存表需要修改所有索引;InnoDB 表用主键索引查询时需要走一次索引查找,用普通索引查询的时候,需要走两次索引查找。而内存表没有这个区别,所有索引的“地位”都是相同的。InnoDB 支持变

2020-06-30 16:22:25

内部临时表

内部临时表和sort buffer,join buffer一样,都用来存放语句执行过程中的中间数据,辅助语句的执行。使用用法 using temporary。使用场景数据一边查询,一边直接得到结果,不需要额外内存。比如:group by 需要计算。join_buffer 是无序数组(单字段,可以重复),sort_buffer 有序数组,内部临时表是二维结构用到二维表的特性需要用到内部临时表,比如 distinct ,group by优化group by 字段加索引

2020-06-30 16:20:33

临时表

临时表内存表和临时表的区别内存表:是用memory引擎的表,这表的数据都放在内存中,重启时会清空数据,但是表结构还在临时表:可以使用各种引擎,如果使用innodb或myisam的话,数据是存到磁盘的,临时表的特性不同session的临时表是可以重名的,有多个session同时创建临时表,并不会因为名字一样而冲突,因为是session级别的(线程独有)不需要担心数据问题,当断开连接或异常重启的时候,临时表会自动被回收临时表的应用分库分表的情况下,用proxy,然后如果使用到每个分区都

2020-06-30 16:18:14

join的优化

join的优化multi_range read优化(mrr)大多数的数据都是按照顺序来新增的,如果按照顺序对主键进行访问,接近于磁盘的顺序读,提高性能根据索引定位到满足条件的记录,将id放入read_rnd_buffer将read_rnd_buffer的id进行递增排序排序后的id数组,依次到主键查记录,作为结果返回稳定性的使用mrr,要用 set optimizer_switch=“mrr_cost_based=off”用explain时,在extra有using MRR,就是使用到了

2020-06-30 16:15:22

如何使用join

如何使用join如果能用到被驱动表的索引,则使用join比拆成多个单表执行的sql来的快使用join的话,让小表做驱动表在决定哪个表做驱动表的时候,应该是两个表按照各自的条件过滤,过滤完成之后,计算参与 join 的各个字段的总数据量,数据量小的那个表,就是“小表”,应该作为驱动表。如果使用Block Nasted-Loop join算法,有可能导致join buffer不够大,导致被驱动表做多次全表扫描,所以在explain的时候Extra字段里面出现Block Nasted-Loop的话,就尽

2020-06-30 16:11:36

kill不生效

kill语句kill不掉的第一种情况,innodb_thread_concurrency的上限了用户在执行kill的时候,处理kill的线程做了两件事把被kill的实例 的运行状态改成 THD::KILL_QUERY(将变量 killed 赋值为 THD::KILL_QUERY);给 被kill的实例 的执行线程发一个信号。一个语句执行过程中有多处“埋点”,在这些“埋点”的地方判断线程状态,如果发现线程状态是 THD::KILL_QUERY,才开始进入语句终止逻辑;如果处于等待状态,必须

2020-06-30 15:48:31

误删数据之后怎么办

误删数据之后怎么办误删行使用delete之后,用Flashback工具闪回,(前提:binlog_format= row和binlog_row_image=Full)单事务的情况:insert的语句,对应的binlog event类型是write_rows event改成Delete_rows eventdelete的语句,把Delete_rows event改成write_rows eventupdate的语句,binlog记录修改前和修改后的语句,两者调换即可建议在备库上执行回滚操作

2020-06-30 15:25:08

如何判断主库的健康

如何判断主库的健康select 1:说明进程还在,但是不能说明主库没问题- 有可能被占满了,设置innodb_thread_concurrency控制innodb的并发线程上限,并发连接如果线程的查询进入等待,则并发连接的计数会-1,所以使用select 1可能线程已经超过innodb_thread_concurrency,全被阻塞住了,但是select 1可用查表判断:mysql> select * from mysql.health_check; 空间满了,binlog在写数据写不

2020-06-30 15:22:46

读写分离导致的问题

读写分离基本的读写分离有两种模式一种是client主动做负载均衡一种是在client和mysql之间有一个proxy来做代理层,两者的区别客户端直连的方式,查询的性能好一点点,架构简单,排查问题容易些,但是数据迁移,主备切换等,都会被感知且调整数据库连接信息带proxy的方式,就后端只需要注意在开发逻辑上,连接维护,后端信息维护等,都直接proxy做,但是对维护团队要求比较高有时候还是会从从库那边读到主库过期的数据,解决方案有以下几种方案强制走主库方案将查询分类,有的强一致的就

2020-06-30 15:14:41

主备切换

主库产生问题之后怎么办,切换备库后,要指定其他的从库的主库为新上来的主库(之前的备库)需要执行一条命令,change masterCHANGE MASTER TO MASTER_HOST=$host_name MASTER_PORT=$port MASTER_USER=$user_name MASTER_PASSWORD=$password //以上是新主库的ip 端口 用户名和密码MASTER_LOG_FILE=$master_log_name MASTER_LOG_POS=$mas.

2020-06-30 15:04:24

数据同步时的并发策略

主备并发同步版本5.5并发复制策略(个人策略)按表分发:每个worker都维护一个hashtable,表示自己正在执行的事务中涉及到哪些表,如果分发的事务中的表,和在worker中大于1个worker的表有事务冲突(有相同的表在执行),就等待,等到只有一个worker有冲突的时候,就把这个事务丢到这个worker如果热点表被多次操作,这样子就只有一个worker执行,相当于单线程按行分发binlog 必须是row,所以必须维护一个hashtable,里面的key为库名+表名+索引a的名称

2020-06-30 14:58:52

数据同步延迟原因及主备切换策略

同步延迟t1为主库a完成事务,写完binlog的时间t2为备库b完成从a传输过来binlog的时间t3为备库执行完binlog的时间t3-t1就是备库和主库之间的延迟时间,在备库执行命令show slave status,会显示seconds_behind_master,就是延迟几秒主备延迟的原因备库所在的服务器比主库的服务器性能来的差,但是他们写入的文件是一样多的,所以尽量保证主备性能一致备库压力大,有些读操作在备库上执行,没有优化,直接大批量读取数据,导致io飙升,从而主备延迟,解决

2020-06-30 14:52:47

数据库的数据一致

数据库主备一致都是用binlog来保证数据库主备一致的流程备库b通过change master命令,设置主库的ip host,用户名,密码,偏移量等,备库b执行start slave命令,备库开启两个线程,io-thread和sql-thread,io负责连接主库a验证用户名,密码之后,去binlog以偏移量为起点开始读,发给b备库b那个binlog之后,写到本地文件,为relay log(中转日志)备库的sql-thread开始读relay-log,解析执行binlog的三个格式

2020-06-30 14:48:35

提高redolog和binlog的写入效率

提高redolog和binlog的写入效率LSNLSN是日志逻辑序列号,单调递增,对应redo log的写入点,每次wirte都是写redo log长度为从LSN到LSN+lengthgroup commit组提交当第一个事务a进到redo log buffer时,他作为组长,然后a提交的时候,整个buffer中的长度length为事务abc加起来的长度,所以一起把事务abc现在的redo log都wirte到page cache中,所以说组员越多,单次提交的文件越多,越节省磁盘的IO

2020-06-30 14:43:34

binlog和redolog的写入机制

binlog的写入机制事务执行过程先把日志写到binlog cache,事务提交时,从binlog cache写入到binlog文件里事务无法被拆分,无论事务多大,都要保证一次写入每个线程都有一个系统分配的binlog cache的大小,由binlog_cache_size控制,超过则写到磁盘中多个binlog cache公用一个binlog文件,从binlog cache到binlog文件有两个步骤write:把日志写到page cache,没有到磁盘,所以速度比较快fsync:把数

2020-06-30 14:40:13

常见问题

业务遇到问题解决短连接(连接数达到设置的max_connections上限)show processlist查看空闲的连接,直接kill查看infomation_schema中的innodb_trx表和show processlist,查询事务内空闲的连接,kill提高max_connections的值减少连接过程的损耗先确认是否被连接行为打挂了,是的话重启的时候加上-skip-grant-tables命令跳过权限校验查询慢的问题索引设计问题紧急上线索引的时候,可以先备库b设置s

2020-06-30 14:04:02

间隙锁

间隙锁如果在查询的后面加上for update表示查询为当前读,而不是读快照,有可能会导致幻读的问题问题重现:在一个事务a中锁住了name为5的数据,然后再事务a期间,另外一个事务b把另外一条数据的name修改为5,此时,事务a再读一次name为5的数据,数据多了一条,导致一个事务里面,前后读到的数据是不一致的,(当前读才会有幻读的问题)只要在这事务里面修改或新增为当前被锁的数据,就会产生幻读为了解决幻读,引入了间隙锁间隙锁锁的是数据之间的间隙,也就是不能新增或删除间隙锁和行锁合成next-

2020-06-30 13:45:49

查询简单语句,却卡住了

如果查询一个简单的语句,却长时间不回的话,可能出现的问题mdl锁:使用show processlist,可以在state看得到是否被锁住了设置performance_schema=on(比设置off会有10%的损耗),通过查询sys.schema_table_lock_waits,然后kill掉即可等flush有可能存在的问题就是有一个表的sleep语句,然后刚好遇到了flush语句(被sleep阻塞了),flush阻塞了后面的select语句,使用show processlist查看

2020-06-30 11:36:47

索引用不上的原因

索引用不上的原因在查询条件那边用函数,或在=前面计算会导致用不上索引,查询条件做类型转化也用不上索引(因为类型转化用上了数据库中的函数CAST(column AS signed int))查询条件中字符集不同也会导致用不上索引,CONVERT(traideid USING utf8mb4)//整改方案是把字符集转换写在=的后面,而不用默认的字符集转换...

2020-06-30 11:30:13

count()用啥好?

按照效率排序的话count(字段)<count(主键id)<count(1)≈count(*)建议使用count(*)count(主键id),先取出到service层,判断不为null,在+1count(1),判断这行有值,取1到service,判断不为null,+1count(字段)设置为不能为null:就直接按行取值,然后按行累加设置可为null:取值到service层,判断不为null,再+1count(*)如果是myISAM,没有条件的话,就直接从文件.

2020-06-30 11:27:07

查看更多

勋章 我的勋章
  • GitHub
    GitHub
    绑定GitHub第三方账户获取
  • 脉脉勋章
    脉脉勋章
    绑定脉脉第三方账户获得
  • 签到新秀
    签到新秀
    累计签到获取,不积跬步,无以至千里,继续坚持!
  • 持之以恒
    持之以恒
    授予每个自然月内发布4篇或4篇以上原创或翻译IT博文的用户。不积跬步无以至千里,不积小流无以成江海,程序人生的精彩需要坚持不懈地积累!
  • 1024勋章
    1024勋章
    #1024程序员节#活动勋章,当日发布原创博客即可获得
  • 勤写标兵Lv4
    勤写标兵Lv4
    授予每个自然周发布9篇以上(包括9篇)原创IT博文的用户。本勋章将于次周周三上午根据用户上周的博文发布情况由系统自动颁发。