下载频道  >  hyy80688的资源
  • InnoDB,快照读,在RR和RC下有何差异

    • 事务总能够读取到,自己写入(update /insert /delete)的行记录 • RC下,快照读总是能读到最新的行数据快照,当然,必须是已提交事务写入的 • RR下,某个事务首次read记录的时间为T,未来不会读取到T时间之后已提交事务写入的记录,以保证连续相同的read读到相同的结果集

    2018-09-03
    50
  • 4种事务的隔离级别

    • 并发事务之间相互干扰,可能导致事务出现读脏,不可重复度,幻读等问题 • InnoDB实现了SQL92标准中的四种隔离级别 (1)读未提交:select不加锁,可能出现读脏; (2)读提交(RC):普通select快照读,锁select /update /delete 会使用记录锁,可能出现不可重复读; (3)可重复读(RR):普通select快照读,锁select /update /delete 根据查询条件情况,会选择记录锁,或者间隙锁/临键锁,以防止读取到幻影记录; (4)串行化:select隐式转化为select ... in share mode,会被update与delete互斥; • InnoDB默认的隔离级别是RR,用得最多的隔离级别是RC

    2018-08-30
    43
  • MyISAM与InnoDB的索引差异

    MyISAM和InnoDB都使用B+树来实现索引: • MyISAM的索引与数据分开存储 • MyISAM的索引叶子存储指针,主键索引与普通索引无太大区别 • InnoDB的聚集索引和数据行统一存储 • InnoDB的聚集索引存储数据行本身,普通索引存储主键 • InnoDB一定有且只有一个聚集索引 • InnoDB建议使用趋势递增整数作为PK,而不宜使用较长的列作为PK

    2018-08-27
    46
  • 数据库索引,到底是什么

    • 数据库索引用于加速查询 • 虽然哈希索引是O(1),树索引是O(log(n)),但SQL有很多“有序”需求,故数据库使用树型索引 • InnoDB不支持哈希索引 • 数据预读的思路是:磁盘读写并不是按需读取,而是按页预读,一次会读一页的数据,每次加载更多的数据,以便未来减少磁盘IO • 局部性原理:软件设计要尽量遵循“数据读取集中”与“使用到一个数据,大概率会使用其附近的数据”,这样磁盘预读能充分提高磁盘IO • 数据库的索引最常用B+树: (1)很适合磁盘存储,能够充分利用局部性原理,磁盘预读; (2)很低的树高度,能够存储大量数据; (3)索引本身占用的内存很小; (4)能够很好的支持单点查询,范围查询,有序性查询;

    2018-08-24
    9
  • InnoDB的七种锁

    (1)自增锁(Auto-inc Locks) (2)共享/排它锁(Shared and Exclusive Locks) (3)意向锁(Intention Locks) (4)插入意向锁(Insert Intention Locks) (5)记录锁(Record Locks) (6)间隙锁(Gap Locks) (7)临键锁(Next-key Locks)

    2018-08-22
    50
  • InnoDB怎么应对高并发

    总结 (1)常见并发控制保证数据一致性的方法有锁,数据多版本; (2)普通锁串行,读写锁读读并行,数据多版本读写并行; (3)redo日志保证已提交事务的ACID特性,设计思路是,通过顺序写替代随机写,提高并发; (4)undo日志用来回滚未提交的事务,它存储在回滚段里; (5)InnoDB是基于MVCC的存储引擎,它利用了存储在回滚段里的undo日志,即数据的旧版本,提高并发; (6)InnoDB之所以并发高,快照读不加锁; (7)InnoDB所有普通select都是快照读;

    2018-08-13
    16
  • InnoDB5项最佳实践

    在大数据量,高并发量的互联网业务场景下,对于MyISAM和InnoDB • 有where条件,count(*)两个存储引擎性能差不多 • 不要使用全文索引,应当使用《索引外置》的设计方案 • 事务影响性能,强一致性要求才使用事务 • 不用外键,由应用程序来保证完整性 • 不命中索引,InnoDB也不能用行锁

    2018-08-09
    1
  • Cache Aside Pattern

    Cache Aside Pattern建议,先操作数据库,再操作缓存。

    2018-07-12
    9
  • 究竟先操作缓存,还是数据库

    (1)读请求,先读缓存,如果没有命中,读数据库,再set回缓存 (2)写请求 (2.1)先缓存,再数据库 (2.2)缓存,使用delete,而不是set

    2018-07-10
    17
  • 缓存,究竟是淘汰,还是修改

    允许cache miss的KV缓存写场景: • 大部分情况,修改value成本会高于“增加一次cache miss”,因此应该淘汰缓存 • 如果还在纠结,总是淘汰缓存,问题也不大

    2018-07-03
    5
关注 私信 TA的资源