MyISAM

2019年开始，新东方APP团队启动了长达半年以上的稳定性建设工作，为什么稳定性如此重要？因为随着每年30%以上的高速增长，现有的后端服务完全扛不住日益增多的用户带来的高并发，高可用场景。所以优化工作势在必行。 如果你是一名java程序员的话，相信你也会很清楚，有时候，在研发功能的时候，仅仅是贴着产品的需求在做开发，功能是都实现了，但是没有考虑到功能在高并发下面是否可用，响应是否及时。这就给以后的线上运行留下很多隐患。 我们做稳定性建设的原因就是要解决这些隐患，提高系统稳定性，提高单台机器的QPS性能。加快接口响应速度，优化数据库的sql查询。 下面看一下优化后的效果图： 以上是单独一台服务器的吞吐率和响应时间曲线图，从图中可以看到，暑期吞吐率增长5倍，服务响应时间从最长的50多秒大幅度减少到0.4秒。优化效果明显。 以下从3方面阐述优化方法： 1、如何定位后端问题 2、如何解决数据库问题 3、如何分析和解决程序问题 一、定位后端问题的方法： kibana 。可以还原线上有问题的接口的参数列表（实时性比较好，统计多台服务器的日志，统一处理）。 听云 用听云监测慢事务，慢接口比较详细，能准确定位接口是sql慢，还是代码哪里慢。 二、数据库知识点和优化 1、2种存储引擎 在MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的

索引这个词，相信大多数人已经相当熟悉了，很多人都知道MySQL的索引主要以B+树为主，但是要问到为什么用B+树，恐怕很少有人能把前因后果讲述的很完整。本文就来从头到尾介绍下数据库的索引。 索引是一种数据结构，用于帮助我们在大量数据中快速定位到我们想要查找的数据。 索引最形象的比喻就是图书的目录了。注意这里的大量，数据量大了索引才显得有意义，如果我想要在[1,2,3,4]中找到4这个数据，直接对全数据检索也很快，没有必要费力气建索引再去查找。索引在mysql数据库中分三类： B+树索引、Hash索引、全文索引 我们今天要介绍的是工作开发中最常接触到innodb存储引擎中的的B+树索引。 要介绍B+树索引，就不得不提二叉查找树，平衡二叉树和B树这三种数据结构。B+树就是从他们仨演化来的。 二叉查找树 首先，让我们先看一张图。 从图中可以看到，我们为user表(用户信息表)建立了一个二叉查找树的索引。图中的圆为二叉查找树的节点，节点中存储了键(key)和数据(data)。 键对应user表中的id，数据对应user表中的行数据。二叉查找树的特点就是任何节点的左子节点的键值都小于当前节点的键值，右子节点的键值都大于当前节点的键值。 顶端的节点我们称为根节点，没有子节点的节点我们称之为叶节点。 如果我们需要查找id=12的用户信息，利用我们创建的二叉查找树索引，查找流程如下： 1.

简单来说，事务就是要保证一级数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的，但MySQL中并不是所有引擎都支持事务，比如Mysql原生的MyISAM引擎就不支持事务。 下面，我们将心InnoDb为例，剖析MySQL在事务支持方面的特定实现。 隔离性与隔离级别 提到事务，你一定会想到ACID（Atomicity、Consistency、Isolation、Durability）,即原子性、一致性、隔离性、持久性，下面我们就来说说其中的I，也就是隔离性。 当数据库上有多个事务同时执行的时候，就会可能会出现脏读、不可重复读、幻读的问题，为了解决这些问题，就有了“隔离级别”的概念。 在谈隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时间，我们要在二者之间找一个平衡点。SQL标准的事务隔离级别有：读未提交、读已提交、可重复读和串行化。 读未提交：一个事务还没有提交时，它做的变更能被别的事务看到。 读已提交：一个事务提交之后，它做的变更才能被其它事务看到。 可重复读：一个事务执行过程中看到的数据，总是和这个事务启动时看到的事务一致。 串行化：对同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 其中“读提交”和“可重复读”比较难理解

Is the internal locking of MySQL sufficient for a small to medium sized website? My tables are MyISAM. There might be a few hundred people concurrently hitting a specific table with SELECT'S and INSERT's. None of the INSERT/UPDATE queries would overlap. That is, no two users will be updating the same comment ID. INSERT's/UPDATE's would be one-off operations---there would be no reading of data and performing additional operations within the same query. Specifically, I am setting up a comment/chat system for my website. At worst, there might be a couple of hundred people performing a SELECT

简单来说，事务就是要保证一级数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的，但MySQL中并不是所有引擎都支持事务，比如Mysql原生的MyISAM引擎就不支持事务。 下面，我们将心InnoDb为例，剖析MySQL在事务支持方面的特定实现。 隔离性与隔离级别 提到事务，你一定会想到ACID（Atomicity、Consistency、Isolation、Durability）,即原子性、一致性、隔离性、持久性，下面我们就来说说其中的I，也就是隔离性。 当数据库上有多个事务同时执行的时候，就会可能会出现脏读、不可重复读、幻读的问题，为了解决这些问题，就有了“隔离级别”的概念。 在谈隔离级别之前，你首先要知道，你隔离得越严实，效率就会越低。因此很多时间，我们要在二者之间找一个平衡点。SQL标准的事务隔离级别有：读未提交、读已提交、可重复读和串行化。 读未提交：一个事务还没有提交时，它做的变更能被别的事务看到。 读已提交：一个事务提交之后，它做的变更才能被其它事务看到。 可重复读：一个事务执行过程中看到的数据，总是和这个事务启动时看到的事务一致。 串行化：对同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。 其中“读提交”和“可重复读”比较难理解

I means copying individual MyISAM table files is: (shut down mysqld and copy the .frm, .myd, and .myi files from one database folder to another) Question: (a) can I use this way to backup MySQL database folder from one server to another server with different MySQL version? (b) can this backup files moved to different OS? (example: debian to centos) Only file-level copy MyISAM tables between versions of servers with the same: - CPU 'endian' ( SPARC != x86 ) - MySQL versions are upgrade-able without conversion (5.0.48 copy to 5.0.52 is bad because of index structure changes, but 5.0.52 copy to 5

(I've seen this question but it's not specific enough for what I want to ask.) I'm setting up a large-ish (a hundred GB or so) log table with an average record size of 100-200 bytes and several indexes (indices?). Insertion rate will be about 100-200 records per second. I will run analytical queries on this table, probably not all of them will hit a suitable index so they might run for a long time and look up a lot of data. What storage engine would you suggest? (Basically MyISAM vs InnoDB.) If using MyISAM, will long queries block inserts? Table size is a concern (not a big one, but still).

如何在两种存储引擎中进行选择？ ① 是否有事务操作？有，InnoDB。 ②是否存储并发修改？有，InnoDB。 ③是否追求快速查询，且数据修改较少？是，MyISAM。 ④是否使用全文索引？如果不引用第三方框架，可以选择MyISAM，但是可以选用第三方框架和InnDB效率会更高。 四、浅谈MVCC MySQL大多数事务型存储引擎实现的都不是简单的行锁。基于提升并发性能的考虑，他们一般都同时实现了多版本并发控制(MVCC)。 可以认为MVCC是行级锁的一个变种，它能在大多数情况下避免加锁操作，因此开销更低。无论怎样实现，它们大都实现了非阻塞的读操作，写操作也只锁定指定的行。 MVCC是通过保存数据在某一个时间点的快照来实现的，也就是说无论事务执行多久，每个事务看到的数据都是一致的。InnoDB的MVCC，是通过在每行记录后面保存两个隐藏的列来实现，这两个列一个保存了行的创建时间，一个保存了行的过期时间(或删除时间)，当然，并非存储的是时间，而是系统版本号。 每开启一个事务，版本号都会递增，事务开始时刻的系统版本号会作为事务的版本号。 id name 创建时间（行版本号） 删除时间(删除版本号) 1 Mary 1 null 2 Jann 1 null 以InnoDB存储引擎的的REPEATABLE READ隔离级别来说： SELECT ​ ①只查询创建时间版本号小于当前事务版本号的数据行

I'm running MySQL 5.6 (64-bit) on Windows 7. I'm testing a DB recently upgraded from MySQL 5.0 on 32-bit Windows 7. (I also copied my.ini, with a few changes) I'm finding that it takes a very long time to establish a connection (on the order of 1 second). As an example, I created a very simple SQL script: select 1 as n; I then ran this in a batch file 10 times which took 10 seconds to complete: mysql -h localhost -u root -D myschema 0< myscript.sql (Yes, there is no password here, this is a test DB listening only to 127.0.0.1) Anyone have an idea why this is so very slow? (See my.ini below)

占位符 来源： https://www.cnblogs.com/Tunan-Ki/p/11939212.html