随笔分类 -  database

MYSQL & mongodb 等数据库
摘要:开发者所说,他为何选用 skiplist The Skip list There are a few reasons: They are not very memory intensive. It's up to you basically. Changing parameters about th 阅读全文
posted @ 2020-06-02 23:07 Ever-Lose 阅读(4488) 评论(0) 推荐(0)
摘要:explain 语句详解 参考:https://segmentfault.com/a/1190000008131735 explain 写在 select 前,如下 mysql> explain select * from user_info where id = 2\G ************* 阅读全文
posted @ 2020-05-28 10:43 Ever-Lose 阅读(250) 评论(0) 推荐(0)
摘要:MongoDB 从一开始就是设计作为分布式数据库的,为了方便不同的机器都能全局唯一的生成 _id,而自增 id 需要在多个服务器上同步其值,费时费力,所以自然得设计成长字符串。 ObjectId 是"_id" 的默认类型,举个官网的例子 ObjectId 是一个字符串,有 24 个字符,使用 12 阅读全文
posted @ 2020-05-04 12:57 Ever-Lose 阅读(3360) 评论(0) 推荐(0)
摘要:先上结论,根据官网的说法是 B 树 然而笔者看到一篇, "云栖社区 MongoDB 为什么使用B 树而不是B+树?" ,里面有人如下回答 实际是B+树,这个在2018年元旦北京的MongoDB专场,我问了WiredTiger引擎的作者,他也确认了是B plus Tree。虽然官方文档写了B树。 现在 阅读全文
posted @ 2020-05-04 10:51 Ever-Lose 阅读(2780) 评论(1) 推荐(1)
摘要:结论 默认不会加读锁!但 MySQL InnoDB 的可重复读并不保证避免幻读,需要应用使用加锁读来保证。而这个加锁度使用到的机制就是 next key locks。 隔离级别说明 MySQL InnoDB事务的隔离级别有四级,默认是“可重复读”(REPEATABLE READ)。 未提交读(REA 阅读全文
posted @ 2020-05-04 00:03 Ever-Lose 阅读(792) 评论(0) 推荐(0)
摘要:数据结构 Mysql 使用 B+树 为什么选择 B+ 树,而非二叉树,红黑树,B 树呢? 二叉树:对于表提供自增整形字段作为建立索引的列,那子元素总是添加去了右侧,导致左子树一直为空,那么查找时就完全退化成了没加索引那样了。 红黑树:红黑树解决了二叉树不平衡的问题。然为什么要费力保持树的平衡性?是因 阅读全文
posted @ 2020-05-03 11:18 Ever-Lose 阅读(759) 评论(0) 推荐(0)
摘要:只获取指定所要的字段 查询某时间段的数据 模糊查询,使用正则 或非等逻辑操作符筛选 条件函数,慎用,效率低。 聚合查询,查询从 10 月 15 日以来到现在,每小时的数量 阅读全文
posted @ 2020-05-03 10:19 Ever-Lose 阅读(2093) 评论(0) 推荐(0)
摘要:示例数据库 原文: https://www.kancloud.cn/kancloud/theory of mysql index/41847 mysql 示例数据库 Employees 地址:https://dev.mysql.com/doc/employee/en/sakila structure 阅读全文
posted @ 2020-05-03 10:17 Ever-Lose 阅读(1103) 评论(1) 推荐(0)
摘要:* 更小的通常更好,更小的数据类型查找速度快占用空间少 * 简单就好,比如使用 Mysql 自建类型存储时间日期,应该用整形存储 IP 地址而非字符串。 * 尽量避免 NULL,NULL 列占用更多空间且不利于索引优化,除了时间日期这样不适合用 0 或者空字符串代替。 阅读全文
posted @ 2020-04-30 18:04 Ever-Lose 阅读(270) 评论(0) 推荐(0)
摘要:简述 redis 本身的下载与编译参见 "官网下载" js 使用 ioredis 来操作。 对于多数 redis 的命令,js 都有函数来代理操作,其格式如下 举个例子, 就等同于 key value 增删改查 命令官方文档 "GETSET key value" 用 JS 操作如下 无序集合操作 简 阅读全文
posted @ 2020-04-30 17:53 Ever-Lose 阅读(353) 评论(0) 推荐(0)
摘要:百万级 字段选择优化 表字段 not null,因为 null 值很难查询优化且占用额外的索引空间,推荐默认数字 0。 数据状态类型的字段,比如 status, type 等等,尽量不要定义负数,如 1。因为这样可以加上 UNSIGNED,数值容量就会扩大一倍。 可以的话用 TINYINT、SMAL 阅读全文
posted @ 2020-04-30 16:21 Ever-Lose 阅读(5423) 评论(0) 推荐(0)
摘要:结论 MySQL从设计上让连接和断开连接都很轻量级,在返回一个小的查询结果方面很高效” MySQL内部每秒能够扫描内存中上百万行数据,相比之下,MySQL响应数据给客户端就慢得多了。在其他条件都相同的时候,使用尽可能少的查询当然是更好的。但是有时候,将一个大查询分解为多个小查询是很有必要的 切分查询 阅读全文
posted @ 2020-04-30 15:22 Ever-Lose 阅读(925) 评论(0) 推荐(0)
摘要:官网:https://sequelize.org/v5/manual/querying.html 定义 model/Post.js 查 常用操作符号 调用语句查,内容长度小于 6 个字符 查 JSON 增 批量增 删 改 阅读全文
posted @ 2020-04-29 11:52 Ever-Lose 阅读(1174) 评论(0) 推荐(0)
摘要:mysql 5.7 官方对于分区的文档:https://dev.mysql.com/doc/refman/5.7/en/partitioning.html 使用场景 千万级别的数据 限制 一个表最多只能有1024个分区。 在MySQL 5.1中,分区表达式必须是整数,或者是返回整数的表达式。在MyS 阅读全文
posted @ 2020-04-29 11:27 Ever-Lose 阅读(456) 评论(0) 推荐(0)
摘要:场景 最近写了一个收集号码的逻辑,早上来 count 了一下 phone 表,发现已经收集到了 33w 条记录。 但细心的我留意到似乎有 id 值很大的记录 咂摸着觉着不对味。 原因 查了查资料这还有个术语,叫 MySQL auto_increment 空洞问题,是因为我插入/更新表的事后偷懒使用了 阅读全文
posted @ 2020-04-29 11:20 Ever-Lose 阅读(1079) 评论(0) 推荐(0)
摘要:查询 JSON 字段比较麻烦,有一下几种办法 若该字段是个JSON对象,用 进行查询 若该字段是个 JSON 数组,用 JSON_CONTAINS(字段, JSON_OBJECT('json属性', "内容")) 举例一张表 CREATE TABLE ( int(11) unsigned NOT N 阅读全文
posted @ 2020-04-29 11:16 Ever-Lose 阅读(5636) 评论(0) 推荐(0)