精华内容
下载资源
问答
  • mysql使用全文搜索引擎
    千次阅读
    2021-01-18 18:37:24

    简单来说,存储引擎就是指表的类型以及表在计算机上的存储方式。

    存储引擎的概念是MySQL的特点,Oracle中没有专门的存储引擎的概念,Oracle有OLTP和OLAP模式的区分。不同的存储引擎决定了MySQL数据库中的表可以用不同的方式来存储。我们可以根据数据的特点来选择不同的存储引擎。

    在MySQL中的存储引擎有很多种,可以通过“SHOW ENGINES”语句来查看。下面重点关注InnoDB、MyISAM、MEMORY这三种。

    一.InnoDB存储引擎

    InnoDB给MySQL的表提供了事务处理、回滚、崩溃修复能力和多版本并发控制的事务安全。在MySQL从3.23.34a开始包含InnnoDB。它是MySQL上第一个提供外键约束的表引擎。而且InnoDB对事务处理的能力,也是其他存储引擎不能比拟的。靠后版本的MySQL的默认存储引擎就是InnoDB。

    InnoDB存储引擎总支持AUTO_INCREMENT。自动增长列的值不能为空,并且值必须唯一。MySQL中规定自增列必须为主键。在插入值的时候,如果自动增长列不输入值,则插入的值为自动增长后的值;如果输入的值为0或空(NULL),则插入的值也是自动增长后的值;如果插入某个确定的值,且该值在前面没有出现过,就可以直接插入。

    InnoDB还支持外键(FOREIGN KEY)。外键所在的表叫做子表,外键所依赖(REFERENCES)的表叫做父表。父表中被字表外键关联的字段必须为主键。当删除、更新父表中的某条信息时,子表也必须有相应的改变,这是数据库的参照完整性规则。

    InnoDB中,创建的表的表结构存储在.frm文件中(我觉得是frame的缩写吧)。数据和索引存储在innodb_data_home_dir和innodb_data_file_path定义的表空间中。

    InnoDB的优势在于提供了良好的事务处理、崩溃修复能力和并发控制。缺点是读写效率较差,占用的数据空间相对较大。

    二.MyISAM存储引擎

    MyISAM是MySQL中常见的存储引擎,曾经是MySQL的默认存储引擎。MyISAM是基于ISAM引擎发展起来的,增加了许多有用的扩展。

    MyISAM的表存储成3个文件。文件的名字与表名相同。拓展名为frm、MYD、MYI。其实,frm文件存储表的结构;MYD文件存储数据,是MYData的缩写;MYI文件存储索引,是MYIndex的缩写。

    基于MyISAM存储引擎的表支持3种不同的存储格式。包括静态型、动态型和压缩型。其中,静态型是MyISAM的默认存储格式,它的字段是固定长度的;动态型包含变长字段,记录的长度不是固定的;压缩型需要用到myisampack工具,占用的磁盘空间较小。

    MyISAM的优势在于占用空间小,处理速度快。缺点是不支持事务的完整性和并发性。

    三.MEMORY存储引擎

    MEMORY是MySQL中一类特殊的存储引擎。它使用存储在内存中的内容来创建表,而且数据全部放在内存中。这些特性与前面的两个很不同。

    每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同,类型为frm类型。该文件中只存储表的结构。而其数据文件,都是存储在内存中,这样有利于数据的快速处理,提高整个表的效率。值得注意的是,服务器需要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要了,可以释放内存,甚至删除不需要的表。

    MEMORY默认使用哈希索引。速度比使用B型树索引快。当然如果你想用B型树索引,可以在创建索引时指定。

    注意,MEMORY用到的很少,因为它是把数据存到内存中,如果内存出现异常就会影响数据。如果重启或者关机,所有数据都会消失。因此,基于MEMORY的表的生命周期很短,一般是一次性的。

    四.怎样选择存储引擎

    在实际工作中,选择一个合适的存储引擎是一个比较复杂的问题。每种存储引擎都有自己的优缺点,不能笼统地说谁比谁好。

    InnoDB:支持事务处理,支持外键,支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高(比如银行),要求实现并发控制(比如售票),那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库,也可以选择InnoDB,因为支持事务的提交(commit)和回滚(rollback)。

    MyISAM:插入数据快,空间和内存使用比较低。如果表主要是用于插入新记录和读出记录,那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比 较低,也可以使用。

    MEMORY:所有的数据都在内存中,数据的处理速度快,但是安全性不高。如果需要很快的读写速度,对数据的安全性要求较低,可以选择MEMOEY。它对表的大小有要求,不能建立太大的表。所以,这类数据库只使用在相对较小的数据库表。

    注意,同一个数据库也可以使用多种存储引擎的表。如果一个表要求比较高的事务处理,可以选择InnoDB。这个数据库中可以将查询要求比较高的表选择MyISAM存储。如果该数据库需要一个用于查询的临时表,可以选择MEMORY存储引擎。

    更多相关内容
  • 本文涵盖了一个简单的C实现的搜索引擎的搭建始末。 我通常使用SQL Server和C #,但我教C/C++的朋友要远离微软。在过去,MySQL不是我想要的数据库,因为标准安装版不支持事务,但它变得越来越成熟。我使用64位InnoDB...
  • 主要介绍了php利用scws实现mysql全文搜索功能的方法,可通过scws分词插件的扩展来实现MySQL全文搜索功能,是非常实用的技巧,需要的朋友可以参考下
  • 全文索引(也称全文检索)是目前搜索引擎使用的一种关键技术。它能够利用【分词技术】等多种算法智能分析出文本文字中关键词的频率和重要性,然后按照一定的算法规则智能地筛选出我们想要的搜索结果。 在MySql中,...
  • MyISAM引擎是一种非事务性的引擎,提供高速存储和检索,以及全文搜索能力,适合数据仓库等查询频繁的应用。MyISAM中,一个table实际保存为三个文件,.frm存储表定义,.MYD存储数据,.MYI存储索引。 InnoDB则是一种支
  • PHP+Mysql+Sphinx高效的站内搜索引擎搭建详释.docx
  • MySQL全文搜索引擎mysqlcft

    千次阅读 2016-10-21 16:44:20
    MySQL在高并发连接、数据库记录数较多的情况下,SELECT … WHERE … LIKE ‘%…%’的全文搜索方式不仅效率差,而且以通配符%开头作查询时,使用不到索引,需要全表扫描,对数据库的压力也很大。MySQL针对这一问题...

    MySQL在高并发连接、数据库记录数较多的情况下,SELECT … WHERE … LIKE ‘%…%’的全文搜索方式不仅效率差,而且以通配符%开头作查询时,使用不到索引,需要全表扫描,对数据库的压力也很大。MySQL针对这一问题提供 了一种全文索引解决方案,这不仅仅提高了性能和效率(因为MySQL对这些字段做了索引来优化搜索),而且实现了更高质量的搜索。但是,至今为 止,MySQL对中文全文索引无法正确支持。

    Mysqlcft 是为 MySQL 5.1.22 ~ 5.1.25 RC 开发的中文全文索引插件,用于解决MySQL无法正确支持中文全文检索的问题。
    这里写图片描述
    特点:
    1、优点:

    精准度很高:采用自创的“三字节交叉切分算法”,对中文语句进行分割,无中文分词词库,搜索精准度远比中文分词算法高,能达到LIKE '%...%"的准确率。
    查询速度快:查询速度比LIKE '%...%"搜索快3~50倍,文章末尾有测试结果;
    标准插件式:以MySQL 5.1全文索引的标准插件形式开发,不修改MySQL源代码,不影响MySQL的其他功能,可快速跟进MySQL新版本;
    支持版本多:支持所有的MySQL 5.1 Release Candidate版本,即MySQL 5.1.22 RC~最新的MySQL 5.1.25 RC;
    支持字符集:支持包括GBK、GB2312、UTF-8、Latin1、BIG5在内的MySQL字符集(其他字符集没有测试过);
    系统兼容好:具有i386和x86_64两个版本,支持32位(i386)和64位(x86_64)CPU及Linux系统;
    适合分布式:非常适合MySQL Slave分布式系统架构,无词库维护成本,不存在词库同步问题。
    

    2、缺点:

    mysqlcft中文全文索引只适用于MyISAM表,因为MySQL只支持对MyISAM表建立FULLTEXT索引;
    MySQL不能静态编译安装,否则无法安装mysqlcft插件;
    基于“三字节交叉切分算法”的索引文件会比海量、ft-hightman等基于“中文分词算法”的索引文件稍大,但不是大很多。
    

    根据我的测试,mysqlcft全文索引的.MYI索引文件是.MYD数据文件的2~6倍。

    搜索引擎使用的一些网址:
    http://www.oschina.net/p/mysqlcft
    点进网站 之后查看右侧栏

    展开全文
  • Mysql5.5以后默认使用InnoDB为搜索引擎 MyISAM是表锁,不支持事务和主外键 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SjkqeO8Y-1605001228437)(images/image-20200404084731063.png)]...

    前言

    MySQL数据库,作为程序员相信各位同学一定不会陌生。如果你感觉陌生,就说明你不是一个合格的程序员。下面为大家介绍MySQL数据库更深层的知识–MySQL默认搜索引擎.

    MySQL默认搜索引擎

    Mysql5.5以后默认使用InnoDB为搜索引擎

    MyISAM是表锁,不支持事务和主外键

    在这里插入图片描述

    InnoDB默认可以创建16个索引

    硬盘

    在这里插入图片描述

    Mysql是存储在硬盘上,因此Redis比Mysql快

    索引

    Mysql官方对索引的定位为:索引是帮助Mysql高效获取数据的数据结构,可以得到索引的本质就是,索引是数据结构。

    可以简单的理解为:排好序的快速查找B+树数据结构,B+树中的B代表平衡(balance) 而不是 二叉(binary)

    检索原理

    在数据之外,数据库系统还维护着满足特定查找算法的数据结构,这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据上实现高级查找算法,这种数据结构,就是索引。下图就是一种可能的索引方式示例:

    在这里插入图片描述

    为了加快Col2的查找,可以维护一个左边所示的二叉树,每个节点分别包含索引键值和一个指向对应数据记录的物理地址的指针,这样就可以运用二叉树在一定的复杂度内获取相应数据,从而快速的检索出符合条件的记录。

    B+树

    B树:Balance Tree,多路平衡查找树

    B+树:加强版多路平衡查找树

    tip:没有B-树,B-树就是B树,中间不是减号而是横线

    Mysql搜索引擎的发展之路

    Mysql InnoDB的搜索引擎 的 底层也不是一来就是 B+树的,而是经过了不断的迭代过程

    • 全部遍历
    • Hash
    • 二叉树
    • 平衡二叉树(AVL)
    • B树
    • B+树

    全部遍历

    相当于全表查询,把每条数据都查找一遍

    Hash

    加速查找速度的数据结构,常见的有两类

    • 哈希,例如HashMap,查询、插入、修改、删除的平均时间复杂度都是O(1)
    • 树:例如平衡二叉搜索树,查询、插入、修改、删除的平均事件复杂度都是O(log2 (n))

    可以看到,不管是读请求,还是写请求,哈希类型的索引,都要比树型的索引更快一些,为什么不用Hash做索引呢,而要设计成树型结构呢?

    假设SQL语句为:

    select * from student where age = 15
    

    我们能够通过Hash就可以很好的用Hash进行解决

    但是随着SQL的复杂化,对于以下范围查找,Hash就搞不定了,也就是说Hash就只能解决查1的问题

    select * from student where age > 15 and age < 20
    

    想想范围/排序等其它SQL条件:

    哈希型的索引,时间复杂度会退化O(n) 而树型的“有序” 特性,依然能够保持 O(log2(n) )

    InnoDB:并不支持Hash索引

    二叉树

    二叉树的特点

    • 一个节点只能有两个子节点,也就是一个节点的度不能超过2
    • 左子节点小于本节点,右子节点大于等于本节点,比我大的向右,比我小的向做

    在这里插入图片描述

    对该二叉树的节点查找发现:

    深度为1的节点查找次数为:1

    深度为2的节点查找次数为:2

    深度为N的节点查找次数为:N

    结论:因此其平均查找长度为:(1+2+2+3+3+3) / 6 = 2.3次

    问题

    • 如果ID是持续递增的话,会出现什么样的结构?

    在这里插入图片描述

    这样树型结构,又会退化到 O(n) 的时间复杂度

    平衡二叉树(AVL)

    结构图

    在这里插入图片描述

    问题

    从算法的数学逻辑来讲,二叉树的查找速度和比较次数都是最小的,那为什么我们选择BTree?因为AVL还有一个问题,那就是 磁盘IO的问题

    • 磁盘IO的次数,就是由树高来决定的,也即磁盘的IO次数最坏的情况下就等于树的高度。

    随着数据量增加,树就会越高,那么查找的就越慢,而且导致的IO操作增加

    解决方法

    我们需要解决的就是树的高度问题,导致磁盘IO过多

    那么就需要将树进行压缩,也就是将原来的瘦高 -> 矮胖,通过降低树的高度达到减少IO的次数

    B树

    B树,又被称为 2-3树,也就是B树上的节点,可能是2,也可能是3

    结构图:

    在这里插入图片描述

    底层原理

    数据库索引是存储在磁盘上的,如果数据很大,必然导致索引的大小也会很大,超过几个G(好比新华字典字数多必然导致目录厚)

    当我们利用索引查询时,是不可能将全部几个G的索引都加载进内存的,我们能做的只能是:

    逐一加载每一个磁盘页,因为磁盘页对应着索引树的节点。

    InnoDB的 page_size

    SHOW GLOBAL STATUS LIKE 'Innodb_page_size';
    

    在这里插入图片描述

    系统从磁盘读取数据到内存时是以磁盘块(block)为单位的,位于同一磁盘块中的数据会被一次性读取出来,而不是需要什么取什么

    InnoDB存储引擎中有页(Page)的概念,页是其磁盘管理的最小单位。

    系统一个磁盘块的存储空间往往没有这么大,因此InnoDB每次申请磁盘空间时都会是若干地址连续磁盘块来达到页的大小16KB。InnoDB在把磁盘数据读入到磁盘时会以页为基本单位,在查询数据时如果一个页中每条数据都有助于定位数据记录的位置,这将会减少磁盘I/O次数,提高效率。

    一句话说:就是多个块填充到一页大小

    检索原理

    B树比平衡二叉树减少了一次IO操作

    在这里插入图片描述

    每个节点占用一个盘块的磁盘空间,一个节点上有两个升序排序的关键字和三个指向子树根节点的指针,指针存储的是子节点所在磁盘块的地址。

    模拟查找关键字29的过程

    • 根据根节点找到磁盘块1,读入内存【磁盘IO操作1次】
    • 比较关键字29在区间(17, 35),找到磁盘块1的指针P2。
    • 根据P2指针找到磁盘块3,读入内存。【磁盘IO操作第2次】
    • 比较关键字29在区间(26, 30),找到磁盘块3的指针P2。
    • 根据P2指针找到磁盘块8,读入内存。【磁盘IO操作3次】
    • 在磁盘块8中的关键字列表,找到关键字29

    分析上述过程,发现需要3次IO操作,和3次内存查找操作,由于内存中的关键字是一个有序表结构,可以利用二分法查找提高效率。而3次磁盘IO操作是影响整个BTree查找效率的决定性因素。BTree相对于AVLTree缩减了节点个数,使每次磁盘IO取到内存的数据都发挥了作用,从而提高了查找效率。

    B+树

    B+树把所有数据放在叶子节点,形成了链表,我们查找数据更方便

    好查,好排序,好划定范围

    B+树结构图

    在这里插入图片描述

    把两种数据结构集成在一块了:树 + 链表

    图中可以看出所有的data信息都移动叶子节点中,而且子节点和子节点之间会有指针指向,这个也是B+树的核心点,这样可以大大提升范围查找效率,也方便遍历整个树。

    • 非叶子节点不在存储数据,数据只存储在同一层的叶子节点上
    • 叶子之间,增加链表,获取所有节点,不再需要中序遍历
    • 这也说明了,B+树的检索性能比B树强

    检索原理

    由于B+树的非叶子只存储键值信息,假设每个磁盘块能存储4个键值及指针信息,那就变成如下结构

    在这里插入图片描述

    B树结构图中可以看出每个节点不仅包含数据的key值,还有data值,而每一页的存储空间是有限的,如果data数据较大时将会导致每个节点(即一个页)能存储的key的数量很小,当存储数量很大时同样会导致B树的深度较大,增大查询时的磁盘IO次数进而影响查询效率。

    Mysql为什么是B+树

    B+树中,所有数据记录节点都是按照键值大小顺序存放在同一层叶子节点上,而非叶子节点上只存储key值信息,这样可以大大加大每个节点存储的key值数量,降低B+树的高度。

    • InnoDB存储引擎的最小存储单元是页,页可以用于存放数据,也可以用于存放键值+指针,在B+树中叶子节点存放数据,而非叶子节点存放键值+指针
    • 索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中,首先找到根页进而去数据页查找到需要的数据

    B+树算法:通过集成B树的特征,B+树相比B树,新增叶子节点与非叶子节点关系,叶子节点包含了键值和数据,非叶子节点只是包含键值和子节点引用,不包含数据。

    通过非叶子节点查询叶子节点获取相应的数据,所有相邻的叶子节点包含非叶子节点使用链表进行结合,叶子节点是顺序并且相邻节点有顺序引用关系。

    结论

    从B树到B+树,B+树在B树的基础上的一种优化使其更适合实现外存储索引结构,InnoDB存储引擎就是用B+树实现的索引结构

    B树和B+树的不同之处

    • 非叶子节点只存储键值信息
    • 所有叶子节点之间都有一个链指针
      了键值和数据,非叶子节点只是包含键值和子节点引用,不包含数据。

    通过非叶子节点查询叶子节点获取相应的数据,所有相邻的叶子节点包含非叶子节点使用链表进行结合,叶子节点是顺序并且相邻节点有顺序引用关系。

    请一键三连,谢谢谢谢谢谢!!!!!!!!!!!!!!!!!!

    展开全文
  • MySQL的几种搜索引擎概述

    千次阅读 2019-02-28 09:30:56
    前言 数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同...MySQL给开发者提供了查询存储引擎的功能,我在这里使用的是MySQL5.1,可...

    前言

    数据库存储引擎是数据库底层软件组织,数据库管理系统(DBMS)使用数据引擎进行创建、查询、更新和删除数据。不同的存储引擎提供不同的存储机制、索引技巧、锁定水平等功能,使用不同的存储引擎,还可以获得特定的功能。现在多种不同的数据库管理系统都支持多种不同的数据引擎。MySQL的核心就是存储引擎。

    存储引擎查看

    MySQL给开发者提供了查询存储引擎的功能,我在这里使用的是MySQL5.1,可以使用:

    SHOW ENGINES

    命令来查看MySQL使用的引擎,命令的输出为(我用的Navicat premium):

    看到mysql给用户提供了这么多存储引擎,包括处理事务安全表的引擎和处理非事务安全表的引擎。

    如果想要查看数据库默认使用哪个引擎,可以通过使用命令:

    SHOW VARIABLES  LIKE  'storage_engine';

    来查看,查询结果为:

    展开全文
  • 基于Sphinx+MySql+Python的站内搜索引擎的设计与实现.pdf
  • Sphinx搜索引擎架构与使用文档(和MySQL结合).pdf
  • 对于MySQL数据库,如果你要使用事务以及行级锁就必须使用INNODB引擎。如果你要使用全文索引,那必须使用myisam,那如何修改修改MySQL引擎为INNODB呢,下面介绍一个修改方法
  • MyISAM在所有MySQL配置里被支持,它是默认的存储引擎,除非你配置MySQL默认使用另外一个引擎。 ◆ MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样...
  • Sphinx搜索引擎架构与使用文档(和MySQL结合)[收集].pdf
  • 什么是全文搜索引擎

    千次阅读 2020-10-23 10:03:49
    对于结构化数据,我们一般都是可以通过关系型数据库(mysql,oracle等)的 table 的方式存储和搜索,也可以建⽴立索引。通过b-tree等数据结构快速搜索数据 非结构化数据:全文数据,指不定长或无固定格式的数据,如...
  • 需要下载的东西 ElasticSearch——...mysql驱动jar包——https://dev.mysql.com/downloads/connector/j/ ElasticSearch 下载完ElasticSearch后解压,然后点击bin目录下的elasticsearc
  • mysql全文索引使用

    万次阅读 2019-04-29 10:27:33
    正好前一段时间项目有一个新的需求,就重新调研了一下mysql全文索引,并对mysql全文索引进行了压测,看看性能怎么样。以判断是否使用。——可想而知,性能不是很好。 下面小编就向大家再说说mysql全文检索。 &...
  • mysql的存储引擎包括:MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDBCluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等,其中InnoDB和BDB提供事务安全表,其他存储引擎都是非事务安全表。 最常使用的2种存储引擎:...
  • MySQL 5.1之前的版本中,默认的搜索引擎是MyISAM,从MySQL 5.5之后的版本中,默认的搜索引擎变更为InnoDB。 2、MyISAM与InnoDB存储引擎的主要特点 MyISAM存储引擎的特点是:表级锁、不支持事务和全文索引,适合...
  • MySQL 5.7.6之前,全文索引只支持英文全文索引,不支持中文全文索引,需要利用分词器把中文...本文使用MySQL 版本是5.7.22,InnoDB数据库引擎mysql原生全文解析器(ngram) MySQL使用全局变量ngram_token_...
  • 前言 在Oracle 和SQL Server等数据库中只有一种...MyISAM管理非事务表,提供高速存储和检索,以及全文搜索能力。 MyISAM是Mysql的默认存储引擎。当create创建新表时,未指定新表的存储引擎时,默认使用MyISAM。每个MyI
  • 开源全文搜索引擎MeiliSearch

    千次阅读 2022-02-09 10:18:59
    MeiliSearch 是用 Rust 写的强大、快速、开源、易于使用和部署的搜索引擎
  • MySQL版Elasticsearch,采用Mybatis-Plus一模一样的语法即可操作搜索引擎,这可能是最好用的Es开源框架.
  • 毕设。项目包含前后端数据交互,爬虫数据收集,算法映射实现,以及测试。后端采用falsk,前端vue,爬虫selenium,处理结巴库,存储mysql。包含所有实现代码。
  • mysql四种常用的搜索引擎

    万次阅读 2018-04-20 10:14:46
    总述: 如果要提供提交、回滚、崩溃恢复能力的...如果只是临时存放数据,数据量不大,并且不需要较高的数据安全性,可以选择将数据保存在内存中的Memory引擎MySQL使用引擎作为临时表,存放查询的中间结果 ...
  • MySQL 5.6版本以前,只有MyISAM存储引擎支持全文引擎, 在5.6版本中,InnoDB加入了对全文索引的支持,但是不支持中文全文索引, 在5.7.6版本,MySQL内置了ngram全文解析器,用来支持亚洲语种的分词, 在使用前请确认...
  • ES(ElasticSearch)分布式全文搜索引擎介绍及使用方式

    万次阅读 多人点赞 2018-11-05 19:34:15
    **ES** 全称 **ElasticSearch** 是一种分布式全文搜索引擎,基于Lucene(全文搜索框架)开发而来。 Lucene是公认的迄今为止的最好用的搜索引擎库,但是他所提供的API对于我们使用者来说,是非常苦恼的,常要花费大量...
  • MyISAM是MySQL的默认存储引擎,基于传统的ISAM类型,支持全文搜索,但不是事务安全的,而且不支持外键。每张MyISAM表存放在三个文件中:frm 文件存放表格定义;数据文件是MYD (MYData);索引文件是MYI (MYIndex)。...
  • 0.场景说明centos7 mysql5.7 InnoDB引擎0.1创建表DROP TABLE IF EXISTS tbl_article_content;CREATE TABLE tbl_article_content (id bigint(40) NOT NULL AUTO_INCREMENT,content text CHARACTER SET utf8 COLLATE ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 138,594
精华内容 55,437
热门标签
关键字:

mysql使用全文搜索引擎

mysql 订阅