mysql .idb .frm .par是什么文件?

mysql .idb .frm .par是什么文件?,第1张

【MySQL文件】MySQL是一个关系型数据库管理系统,由瑞典MySQL AB 公司开发,目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统,在 WEB 应用方面MySQL是最好的 RDBMS (Relational Database Management System,关系数据库管理系统) 应用软件之一。MySQL所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL文件就是SQL文件,里面就是建表语句 以.SQL为后缀。SQL脚本是包含一到多个SQL命令的SQL语句。以将这些SQL脚本放在一个文本文件中(SQL脚本文件),然后通过相关的命令执行这个SQL脚本文件。【IDB文件】IDB智能数据库系统(multimedia intelligent database system)是一个对象数据库管理系统。智能数据库是研究利用人的推理、想像、记忆原理,实现对数据库的存储、搜索和修改。通过有效的组织,能够满足人们快速检索和修改数据库的要求。IDB文件是一种 MSDev 中间层文件。当IDB文件在IDA打开,数据解压到的文件的集合。后的数据库被关闭时,该文件被压缩回IDB文件。这使得更快的性能,同时在数据库打开和较低的磁盘使用时关闭。<H1 >其他IDB格式: </H1 >在调试过程中由一个Visual Studio程序中创建的中间文件,如Visual C, 节省了编译器的状态,并用于最小的重建计划和增量编译。【PAR文件】PAR文件为交换文件,主要是Windows环境下的文件名 。绝大多数DOS文件名后缀在Windows下继续有效,但Windows本身也引出了许多种崭新的后缀名,如:*.drv为设备驱动程序(Driver)、*.fon和*.fot都是字库文件、*.grp为分组文件(Group)、*.ini为初始化信息文件 (Initiation)、*.pif为DOS环境下的可执行文件在Windows下执行时所需要的文件格式、*.crd即卡片文件(Card)、*.rec即记录器宏文件(Record)、*.wri即文本文件(Write),它是字处理write.exe生成的文件、*.doc和*.rtf也是文本文件(Document),它们是Word产生的文件、*.cal为日历文件、*.clp是剪贴板中的文件格式、*.htm和 *.html即主页文件、*.par为交换文件、*.pwl为口令文件(Password)等等。【FRM文件】FRM文件是文本类型文件,用记事本就可以打开,而且也可以保存。FRM文件扩展名信息:1.表单2.Frame Maker或Frame Builder文档3.Oracle可执行表(3.0版或早期版本)4.Visual Basic表单5.WordPerfect Merge表单6.DataCAD标志报表文件。

自己曾经做过一个网盘项目。刚开始由于需要快速地从0到1建设上线,所以没有对核心文档表进行分表。当然我的架构理念也是“按需架构设计”。产品需求在没有明确的长远计划的情况下以“小步快跑,赶超竞品”为主。后期由于产品功能触达目标用户群需求点、产品用户体验不断提升、产品多方位导流、加强产品推广文档表每天有百万数据增长量。不得不对文档表进行按用户id分表。当时产品功能已全覆盖文档的生命周期。产品功能已丰富多彩。修改所有关联文档表的业务代码为按用户id分表开发测试成本非常高。上线后线上问题不可控。经过考虑在业务代码最底层DB层进行SQL语句解析来进行用户id分表处理。这样的话开发测试成本都非常低。上线后有问题方便回滚和追查原因。

今天为大家介绍Python/PHP两种MySQL语句解析器。当时网盘项目用的是PHP编程语言开发。

Python的SQL语句解析器 。个人推荐使用moz_sql_parser库。经调研官方的sqlparse库解析出来的语句段无法满足需求也很难理解。

1、Python moz_sql_parser库安装

2、Python moz_sql_parser SQL语句解析

3、Python moz_sql_parser总结

PHP的SQL语句解析器。 个人推荐使用PhpMyAdmin的sql-parser组件。PhpMyAdmin是经过 历史 检验可信赖的。

1、PHP PhpMyAdmin/sql-parser安装

2、PHP PhpMyAdmin/sql-parser SQL语句解析

3、PHP PhpMyAdmin/sql-parser总结

大家有什么问题可以发评论沟通。

MySQL 前缀索引能有效减小索引文件的大小,提高索引的速度。但是前缀索引也有它的坏处:MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引,也不能把它们用作覆盖索引(Covering Index)。

集一个索引包含多个列(最左前缀匹配原则)

索引列的值必须唯一,但允许有空值

全文索引为FUllText,在定义索引的列上支持值的全文查找,允许在这些索引列中插入重复值和空值,全文索引可以在CHAR,VARCHAR,TEXT类型列上创建

设定主键后数据会自动建立索引,InnoDB为聚簇索引

即一个索引只包含单个列,一个表可以有多个单列索引

覆盖索引是指一个查询语句的执行只用从所有就能够得到,不必从数据表中读取,覆盖索引不是索引树,是一个结果,当一条查询语句符合覆盖索引条件时候,MySQL只需要通过索引就可以返回查询所需要的数据,这样避免了查到索引后的回表 *** 作,减少了I/O效率

查看索引

列名解析:

删除索引

查看:

删除前:

删除后:

普通的索引,没有什么介绍

查看:(注意和前缀索引Sub_part的区别)

当索引的列是unique的时候,会生成唯一索引,唯一索引关于null有下列两种情况

SQLSERVER 下的唯一索引的列,允许null值,但最多允许有一个空值

MYSQL下的唯一索引的列,允许null值,并且允许多个空值

查看:

会建立两个索引,一个非聚簇索引,一个是唯一索引

结果:

可以插入两个空值(明人不说暗话,我喜欢MySQL)

一方面,它不会索引所有字段所有字符,会减小索引树的大小.

另外一方面,索引只是为了区别出值,对于某些列,可能前几位区别很大,我们就可以使用前缀索引。

一般情况下某个前缀的选择性也是足够高的,足以满足查询性能。对于BLOB,TEXT,或者很长的VARCHAR类型的列,必须使用前缀索引,因为MySQL不允许索引这些列的完整长度。

查看:

查看:

复合索引的最左前缀匹配原则

对于复合索引,查询在一定条件才会使用该索引

减少开销。 建一个联合索引(col1,col2,col3),实际相当于建了(col1),(col1,col2),(col1,col2,col3)三个索引。每多一个索引,都会增加写 *** 作的开销和磁盘空间的开销。对于大量数据的表,使用联合索引会大大的减少开销!

覆盖索引。 对联合索引(col1,col2,col3),如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么MySQL可以直接通过遍历索引取得数据,而无需回表,这减少了很多的随机io *** 作。减少io *** 作,特别的随机io其实是dba主要的优化策略。所以,在真正的实际应用中,覆盖索引是主要的提升性能的优化手段之一。

效率高。 索引列越多,通过索引筛选出的数据越少。有1000W条数据的表,有如下sql:select from table where col1=1 and col2=2 and col3=3,假设假设每个条件可以筛选出10%的数据,如果只有单值索引,那么通过该索引能筛选出1000W10%=100w条数据,然后再回表从100w条数据中找到符合col2=2 and col3= 3的数据,然后再排序,再分页;如果是联合索引,通过索引筛选出1000w10% 10% *10%=1w。

在模糊搜索中很有效,搜索全文中的某一个字段,可以参考这篇博文

: https://zhuanlan.zhihu.com/p/88275060

我们先进行下面一个实验看看InnoDB下的主键索引的一个现象。

查看:

我们插入进去的时候,数据的id都是乱序的,为什么这里最后select查询出来的结果都是进行了排序?

这是因为InnoDB索引底层实现的是B+tree,B+tree具有下列的特点:

所以上面的排序是为了使用B+tree的结构 ,B+tree为了范围搜索,将主键按照从小到大排序后,拆分成节点。后续还有新的节点进入的时候,和B-tree相同的 *** 作,会进行分裂。

一般来说,聚簇索引的B+tree都是三层

InnoDB中主键索引一定是聚簇索引,聚簇索引一定是主键索引。

为什么这里辅助索引叶子结点不直接存储数据呢?

MYISAM只有非聚簇索引,索引最终指向的都是物理地址。

Q:既然有回表的存在,那么聚簇索引的优势在哪里?

Q:主键索引作为聚簇索引需要注意什么

在查询语句中使用LIke关键字进行查询时,如果匹配字符串的第一个字符为"%",索引不会使用。如果“%”不是在第一位,索引就会使用

多列索引是在表的多个字段上创建的索引,满足最左前缀匹配原则,索引才会被使用

查询语句只有Or关键字时候,如果OR前后的两个条件都是索引,这这次查询将会使用索引,否则Or前后有一个条件的列不是索引,那么查询中将不使用索引


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8565447.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-18
下一篇 2023-04-18

发表评论

登录后才能评论

评论列表(0条)

保存