MyISAM

Below is the ammount of rows for 2 tables in my mysql DB 1 is myisam the other innodb, can someone tell me why the innodb one has this ~ in front of the number? These numbers came from phpmyadmin 10,308 MyISAM ~118,011 InnoDB phpMyAdmin uses SHOW TABLE STATUS to get information for your tables. From the documentation : Rows The number of rows. Some storage engines, such as MyISAM, store the exact count. For other storage engines, such as InnoDB, this value is an approximation, and may vary from the actual value by as much as 40 to 50%. In such cases, use SELECT COUNT(*) to obtain an accurate

MySQL 的基本存储结构 MySQL的基本存储结构是 页 ： 各个数据页可以组成一个双向链表，每个数据页中的记录又可以组成一个单向链表 所以说，如果我们写select * from user where indexname = 'xxx’这样没有进行任何优化的sql语句，默认会这样做： 定位到记录所在的页：需要遍历双向链表，找到所在的页 从所在的页内中查找相应的记录：由于不是根据主键查询，只能遍历所在页的单链表了 很明显，在数据量很大的情况下这样查找会很慢！这样的时间复杂度为 O（n） 。 使用索引之后，会对索引字段构建一个B+树，其实就是将无序的数据变成有序(相对)，通过二分查找，快速定位数据，时间复杂度近似为O(logn) MySQL索引简介 MySQL索引使用的数据结构主要有 BTree索引 和 哈希索引 。对于哈希索引来说，底层的数据结构就是哈希表，因此在绝大多数需求为单条记录查询的时候，可以选择哈希索引，查询性能最快；其余大部分场景，建议选择BTree索引。 BTree索引 MySQL的BTree索引使用的是B树中的B+Tree，但对于主要的两种存储引擎的实现方式是不同的。 MyISAM : B+Tree叶节点的data域存放的是数据记录的地址。在索引检索的时候，首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，则取出其 data 域的值，然后以 data

目录 Zabbix 数据清理的一系列操作 一、问题 二、解决办法 Zabbix 数据清理的一系列操作 基本信息： Zabbix 版本 4.0.9 MySQL 版本 5.5 一、问题 我们将 Zabbix 的数据存放在测试环境的 RDS (阿里云)上，但是这个 RDS 购买的时候就只有 10G 的存储，所以监控没有几个月，我们的数据库就报存储空间不足的预警了。 首先进行排查，是哪些表占用的存储空间比较多呢，我们发现主要是 history 和 history_uint 这两个表。占用空间最大的是 history_uint 表。 那么这两个表分别是存储什么内容呢？ history_uint 该表存储的是监控项的无符号整型的数据。 该数据的保存时长，取决于在监控项设置的 历史数据保留时长。 CREATE TABLE `history_uint` ( `itemid` bigint(20) unsigned NOT NULL, `clock` int(11) NOT NULL DEFAULT '0', `value` bigint(20) unsigned NOT NULL DEFAULT '0', `ns` int(11) NOT NULL DEFAULT '0', KEY `history_uint_1` (`itemid`,`clock`) ) ENGINE=InnoDB

事务 概念说明： DDL语句：特指修改表结构的语句,如增删表字段等 DML语句：特指增删改查等sql语句 基本知识 事务的基本属性 原子性 原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚 一致性 一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态 拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。 隔离性 隔离性是当多个用户并发访问数据库时，比如操作同一张表时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。 持久性 持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。 数据库隔离现象 脏读 事务B读取到事务A尚为提交的数据变更 不可重复读 事务B前后两次读取一条记录之间，该记录被事务A修改并提交，导致事务B读到了不一样的结果 幻读 事务B按条件匹配到n条记录并修改，但由于修改过程中事务A新插入符合条件的记录，导致事务B更新完成后仍发现有符合条件的数据未被更新。 幻读与不可重复读在理解上差不多，区别是一个是修改数据一个是新增数据 数据库隔离级别

数据库锁模块 MyISAM与InnoDB关于锁方面的区别是什么？ MyISAM默认用的是表级锁，不支持行级锁( 在对数据库进行操作时只会锁住被操作的行 ) InnoDB默认用的是行级锁，也支持表级锁( 在对数据库进行操作时会锁住整张表 ) MyISAM不支持事务 InnoDB支持事务 数据库操作不走索引时使用的是表级锁 MyISAM 在该引擎下会默认添加表锁，当对数据进行select操作时会为表添加一个表级别的读锁；当进行update、insert和delete操作时会自动加上表级别的写锁。 适用场景 频繁执行全表count语句，MyISAM中有一个变量保存了整个表的行数 对数据进行增删改的频率不高(因为增删改会涉及到锁表操作)，查询非常频繁 没有事务的场景 InnoDB 在该引擎下会默认使用的是行锁，行级锁与表级锁的共享性和排它性是一样的，只不过作用的范围不同，行级锁只作用于被上锁的行。 适用场景 数据增删改查都相当频繁 可靠性要求比较高，要求支持事务 数据库锁的分类 读锁 读锁又被称为 共享锁 ，因为一个会话对数据库进行读操作不会阻塞其它会话的读操作，但是会阻塞其它会话的写操作。 在进行select操作的后面加上for update将会添加排它锁，加lock in share mode会添加共享锁 写锁 写锁又被称为 排它锁

索引相关 关于MySQL的索引,曾经进行过一次总结,文章链接在这里 Mysql索引原理及其优化. 1. 什么是索引? 索引是一种数据结构,可以帮助我们快速的进行数据的查找. 2. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引. 3. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要知道Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据. B+树底层实现是多路平衡查找树 .对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据. 那么可以看出他们有以下的不同: hash索引进行等值查询更快(一般情况下),但是却 无法进行范围查询 . 因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围. hash索引不支持使用索引进行排序 ,原理同上. hash索引不支持模糊查询 以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测

I am pretty sure there should be a way to search for hashtags using Full-Text index in MyISAM table. Default setup would do the following: textfield hashtag #hashtag #two #hashtag #hashtag SELECT * FROM table WHERE MATCH(textfield) AGAINST ('#hashtag') > | hashtag | > | #hashtag | > | #two #hashtag #hashtag | While it should return only 2nd and 3rd rows instead. It looks like hashtag is treated as a word delimiter, so it is "removed" before the search begins. What should I do to enable indexing and searching for terms containing # as part of the word? As documented under Fine-Tuning MySQL Full

Here is a table I made: mysql> show create table notes; +-------+----------------------------------------------------+ | Table | Create Table | +-------+----------------------------------------------------+ | notes | CREATE TABLE `notes` ( `id` int(11) NOT NULL auto_increment, `note` text NOT NULL, `status` enum('active','hidden','deleted','followup','starred') default NULL, `created` datetime NOT NULL, `last_updated` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 | +-------+-----------------------------------

1.mysql内存优化原则 a. 将尽量多的内存分配给mysql做缓存，但是也要给操作系统和其他程序预留足够内存。 b. MyISAM的数据文件读取依赖于操作系统的io，因此如果有MyISAM表，就要预留更多的内粗给操作系统做io缓存。 c. 合理设置排序区、链接区等缓存大小。 2.MyISAM内存优化 MyISAM没有特别的缓存机制，完全依赖于操作系统的io缓存 2.1 key_buffer_size key_buffer_size决定MyISAM索引块缓存去的大小，直接影响MyISAM表的存取效率。对于一般MyISAM数据库，建议至少将1/4可用内存分配给key_buffer_size 2.2 read_buffer_size和read_rnd_buffer_size 如果需要经常顺序扫描MyISAM表，可以通过增大read_buffer_size的值来提高性能。但是要注意它是每个session独占的，如果默认值太大，就可能浪费内存，造成物理内存耗尽。 对于要做排序的MyISAM表查询，如带有order by子句的sql，适当增大read_rnd_buffer_size，来改善性能。它也是每个session独占的。 3 InnoDB内存优化 InnoDB的缓存机制和MyISAM不太相同。InnoDB用一块内存区做IO缓存池，该缓存池不仅用来缓存InnoDB的索引块