怎么给mysql设置默认字符集和排序规则

怎么给mysql设置默认字符集和排序规则,第1张

项目用到mysql,但是从数据库中读取数据库中读取的数据中文乱码,然后排查出是因为mysql字符集设置有问题,在这里总结一下mysql如何设置默认字符集

>

数值,典型代表为 tinyint,int,bigint

浮点/定点,典型代表为 float,double,decimal 以及相关的同义词

字符串,典型代表为 char,varchar

时间日期,典型代表为 date,datetime,time,timestamp

二进制,典型代表为 binary,varbinary

类型

枚举类型

集合类型

大对象,比如 text,blob

json 文档类型

一、数值类型(不是数据类型,别看错了)如果用来存放整数,根据范围的不同,选择不同的类型。

以上是几个整数选型的例子。整数的应用范围最广泛,可以用来存储数字,也可以用来存储时间戳,还可以用来存储其他类型转换为数字后的编码,如 IPv4 等。示例 1用 int32 来存放 IPv4 地址,比单纯用字符串节省空间。表 x1,字段 ipaddr,利用函数 inet_aton,检索的话用函数 inet_ntoa。

查看磁盘空间占用,t3 占用最大,t1 占用最小。所以说如果整数存储范围有固定上限,并且未来也没有必要扩容的话,建议选择最小的类型,当然了对其他类型也适用。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl总用量 30G3541825 861M -rw-r----- 1 mysql mysql 860M 12月 10 11:36 t1ibd3541820 989M -rw-r----- 1 mysql mysql 988M 12月 10 11:38 t2ibd3541823 12G -rw-r----- 1 mysql mysql 12G 12月 10 11:39 t3ibd

二、浮点数 / 定点数先说 浮点数,float 和 double 都代表浮点数,区别简单记就是 float 默认占 4 Byte。float(p) 中的 p 代表整数位最小精度。如果 p > 24 则直接转换为 double,占 8 Byte。p 最大值为 53,但最大值存在计算不精确的问题。再说 定点数,包括 decimal 以及同义词 numeric,定点数的整数位和小数位分别存储,有效精度最大不能超过 65。所以区别于 float 的在于精确存储,必须需要精确存储或者精确计算的最好定义为 decimal 即可。示例 3创建一张表 y1,分别给字段 f1,f2,f3 不同的类型。mysql-(ytt/3305)->create table y1(f1 float,f2 double,f3 decimal(10,2));Query OK, 0 rows affected (003 sec)

三、字符类型字符类型和整形一样,用途也很广。用来存储字符、字符串、MySQL 所有未知的类型。可以简单说是万能类型!

char(10) 代表最大支持 10 个字符存储,varhar(10) 虽然和 char(10) 可存储的字符数一样多,不同的是 varchar 类型存储的是实际大小,char 存储的理论固定大小。具体的字节数和字符集相关。示例 4例如下面表 t4 ,两个字段 c1,c2,分别为 char 和 varchar。mysql-(ytt/3305)->create table t4 (c1 char(20),c2 varchar(20));Query OK, 0 rows affected (002 sec)

所以在 char 和 varchar 选型上,要注意看是否合适的取值范围。比如固定长度的值,肯定要选择 char;不确定的值,则选择 varchar。

四、日期类型日期类型包含了 date,time,datetime,timestamp,以及 year。year 占 1 Byte,date 占 3 Byte。 

time,timestamp,datetime 在不包含小数位时分别占用 3 Byte,4 Byte,8 Byte;小数位部分另外计算磁盘占用,见下面表格。

注意:timestamp 代表的时间戳是一个 int32 存储的整数,取值范围为 '1970-01-01 00:00:01000000' 到 '2038-01-19 03:14:07999999';datetime 取值范围为 '1000-01-01 00:00:00000000' 到 '9999-12-31 23:59:59999999'。

综上所述,日期这块类型的选择遵循以下原则:

1 如果时间有可能超过时间戳范围,优先选择 datetime。2 如果需要单独获取年份值,比如按照年来分区,按照年来检索等,最好在表中添加一个 year 类型来参与。3 如果需要单独获取日期或者时间,最好是单独存放,而不是简单的用 datetime 或者 timestamp。后面检索时,再加函数过滤,以免后期增加 SQL 编写带来额外消耗。

4 如果有保存毫秒类似的需求,最好是用时间类型自己的特性,不要直接用字符类型来代替。MySQL 内部的类型转换对资源额外的消耗也是需要考虑的。

示例 5

建立表 t5,对这些可能需要的字段全部分离开,这样以后写 SQL 语句的时候就很容易了。

当然了,这种情形占用额外的磁盘空间。如果想在易用性与空间占用量大这两点来折中,可以用 MySQL 的虚拟列来实时计算。比如假设 c5 字段不存在,想要得到 c5 的结果。mysql-(ytt/3305)->alter table t5 drop c5, add c5 year generated always as (year(c1)) virtual;Query OK, 1 row affected (246 sec)Records: 1  Duplicates: 0  Warnings: 0

五、二进制类型

binary 和 varbinary 对应了 char 和 varchar 的二进制存储,相关的特性都一样。不同的有以下几点:

binary(10)/varbinary(10) 代表的不是字符个数,而是字节数。

行结束符不一样。char 的行结束符是 \0,binary 的行结束符是 0x00。

由于是二进制存储,所以字符编码以及排序规则这类就直接无效了。

示例 6

来看这个 binary 存取的简单示例,还是之前的变量 @a。

切记!这里要提前计算好 @a 占用的字节数,以防存储溢出。

六、位类型

bit 为 MySQL 里存储比特位的类型,最大支持 64 比特位, 直接以二进制方式存储,一般用来存储状态类的信息。比如,性别,真假等。具有以下特性:

1 对于 bit(8) 如果单纯存放 1 位,左边以 0 填充 00000001。2 查询时可以直接十进制来过滤数据。3 如果此字段加上索引,MySQL 不会自己做类型转换,只能用二进制来过滤。

示例 7

创建表 c1, 字段性别定义一个比特位。mysql-(ytt/3305)->create table c1(gender bit(1));Query OK, 0 rows affected (002 sec)

mysql-(ytt/3305)->select cast(gender as unsigned)  'f1' from c1;+------+| f1   |+------+|    0 ||    1 |+------+2 rows in set (000 sec)

过滤数据也一样,二进制或者直接十进制都行。mysql-(ytt/3305)->select conv(gender,16,10) as gender \   -> from c1 where gender = b'1'; +--------+| gender |+--------+| 1      |+--------+1 row in set (000 sec)    mysql-(ytt/3305)->select conv(gender,16,10) as gender \    -> from c1 where gender = '1';+--------+| gender |+--------+| 1      |+--------+1 row in set (000 sec)

其实这样的场景,也可以定义为 char(0),这也是类似于 bit 非常优化的一种用法。

mysql-(ytt/3305)->create table c2(gender char(0));Query OK, 0 rows affected (003 sec)

那现在我给表 c1 简单的造点测试数据。

mysql-(ytt/3305)->select count() from c1;+----------+| count() |+----------+| 33554432 |+----------+1 row in set (137 sec)

把 c1 的数据全部插入 c2。

mysql-(ytt/3305)->insert into c2 select if(gender = 0,'',null) from c1;Query OK, 33554432 rows affected (2 min 1880 sec)Records: 33554432  Duplicates: 0  Warnings: 0

两张表的磁盘占用差不多。root@ytt-pc:/var/lib/mysql/3305/ytt# ls -sihl总用量 19G4085684 933M -rw-r----- 1 mysql mysql 932M 12月 11 10:16 c1ibd4082686 917M -rw-r----- 1 mysql mysql 916M 12月 11 10:22 c2ibd

检索方式稍微有些不同,不过效率也差不多。所以说,字符类型不愧为万能类型。

七、枚举类型

枚举类型,也即 enum。适合提前规划好了所有已经知道的值,且未来最好不要加新值的情形。枚举类型有以下特性:

1 最大占用 2 Byte。2 最大支持 65535 个不同元素。3 MySQL 后台存储以下标的方式,也就是 tinyint 或者 smallint 的方式,下标从 1 开始。4 排序时按照下标排序,而不是按照里面元素的数据类型。所以这点要格外注意。

示例 8

创建表 t7。mysql-(ytt/3305)->create table t7(c1 enum('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (003 sec)

八、集合类型

集合类型 SET 和枚举类似,也是得提前知道有多少个元素。SET 有以下特点:

1 最大占用 8 Byte,int64。2 内部以二进制位的方式存储,对应的下标如果以十进制来看,就分别为 1,2,4,8,,pow(2,63)。3 最大支持 64 个不同的元素,重复元素的插入,取出来直接去重。4 元素之间可以组合插入,比如下标为 1 和 2 的可以一起插入,直接插入 3 即可。

示例 9

定义表 c7 字段 c1 为 set 类型,包含了 8 个值,也就是下表最大为 pow(2,7)。

mysql-(ytt/3305)->create table c7(c1 set('mysql','oracle','dble','postgresql','mongodb','redis','db2','sql server'));Query OK, 0 rows affected (002 sec)

插入 1 到 128 的所有组合。

mysql-(ytt/3305)->INSERT INTO c7WITH RECURSIVE ytt_number (cnt) AS (        SELECT 1 AS cnt        UNION ALL        SELECT cnt + 1        FROM ytt_number        WHERE cnt < pow(2, 7)    )SELECT FROM ytt_number;Query OK, 128 rows affected (001 sec)Records: 128  Duplicates: 0  Warnings: 0

九、数据类型在存储函数中的用法

函数里除了显式声明的变量外,默认 session 变量的数据类型很弱,随着给定值的不同随意转换。

示例 10

定义一个函数,返回两个给定参数的乘积。定义里有两个变量,一个是 v_tmp 显式定义为 int64,另外一个 @vresult 随着给定值的类型随意变换类型。

简单调用下。

mysql-(ytt/3305)->select ytt_sample_data_type(1111,222) 'result';+--------------------------+| result                   |+--------------------------+| The result is: '246642' |+--------------------------+1 row in set (000 sec)

总结

本篇把 MySQL 基本的数据类型做了简单的介绍,并且用了一些容易理解的示例来梳理这些类型。我们在实际场景中,建议选择适合最合适的类型,不建议所有数据类型简单的最大化原则。比如能用 varchar(100),不用 varchar(1000)。

你要是用一个可视化 *** 作的界面就简单了,就比如navicat for mysql右键数据库-->数据库属性--->字符集--->utf-8 unicode /排序规则--->utf8-gernal-ci就行了

大数据量实时统计排序分页查询 (并发数较小时) 的瓶颈不是函数(count,sum等)执行,

不是having, 也不是order by,甚至不是表join, 导致慢的原因就在于“数据量太大本身”

就是将表划分为M份相互独立的部分,可以是分表,也可以是不分表但冗余一个取模结果字段

实际结果是不分表比分表更加灵活,只需稍加配置,就可以动态切分大表,随意更改M的大小。

将1条慢sql(大于30秒)拆分成为N条查询速度巨快的sql(单条sql执行时间控制在20毫秒以内)

然后再web应用中以适当的线程数去并发查询这些执行时间快的N条小sql再汇总结果

第一步查询中去并发执行这N条小sql, 只取排序字段和标识字段,其他字段一律丢弃

汇总结果后定位出当前页面要显示的pageNum条数据,再进行第二步查询,取出页面上需要展示的所有字段

PS:这一点是至关重要的,其他几点都可以不看,这点是最关键的。慢慢解释一下:

a) 第一种方式是把数据库中所有记录(只取排序字段和标识字段并且不做任何sum,count having order by等 *** 作)

全部拉到web应用中,在web应用中完成所有的计算

b) 第二种方式是把数据库中所有记录做sum count having等 *** 作之后的所有行数拉到web应用中,在web应用中完成剩余计算

c) 第三种方式是把数据库中所有记录做sum count having order by等 *** 作之后把limit后的数据拉到web应用中,

在web应用中对limit后的数据再计算

显然,第一种方式 数据库什么活都不做只取数据 是不可行的。以lg_order_count_seller为例,1500万行,

如果只算id, seller_id和order_count 这三个bigint类型,至少需要拉831500 0000 = 360000000=340M,

拉到内存中之后存储需要8415000000= 460M,这还不算List是的2的n次方这个特点和计算排序等的内存开销,

不仅数据库与web应用机器IO扛不住,就是应用自身恐怕也要OOM了。

第二种方式,所有记录做sum count having等 *** 作之后,由于是group by seller_id的,总得数据量变为100万(就是卖家总数),

这样子一来,共需要拉83100 0000 = 23M,拉到内存之后,需要84100 0000 = 30M, 再算上List是的2的n次方这个特点和

计算排序等的内存开销也不会超过100M, IO的时间和内存开销勉强可以考虑接受。

第三种方式,所有记录做sum count having order by等 *** 作之后把limit后的数据拉到web应用中,因为做了limit,所以,

数据量很小了,无论是IO还是内存开销都已经很小了。可以忽略。

综合以上三种,第三种方式适用于页面的前n页和后n页,因为这个limit的数据量随着页数的增大而增大,

当大到每个切分后的小表的数据量时就转为第二种方式了。

第二种方式适用于页面的第[n+1, totaoPageNum-n]页。

切分成N条小sql后并行执行时排序不稳定性的解决办法

① 问题描述:

优化之前,还是是一条大慢sql查询时,由于数据库排序是稳定排序,

所以当两条记录排序字段值相同时他们在页面上的页码位置是固定的。

优化之后,当并行执行这N条小sql时,由于无法控制这些小sql的先后执行顺序,

导致在web应用中当两条记录的排序字段值相同时在页面上的页码位置是随机的。

② 解决办法:

除了拉标识字段(seller_id)和排序字段(order_count_sum)之外,再取一个unique(id)的字段,当两条记录的排序字段值相同时,再用这个unique的字段(在卖家监控中这个字段是id)进行第二次排序这样就解决了排序不稳定的问题。

③ 也许,看到这里会有疑问,为什么不用seller_id?seller_id也是唯一, 这样子不是少取id这个字段,减少IO了?

seller_id虽然也是唯一,可以辅助排序,但是不要忘记数据库的排序规则是:

如果两列的值相等,那么序号在前的排在前面,这里的序号就是主键(自动生成,autoincrement),

如果用seller_id的话还是不能保证排序的稳定性,只能用主键id

优先加载页面上的主要元素,然后再去异步加载次要元素,

反应在卖家监控页面中,查数据和查页页码的sql语句基本相同,是在竞争同一资源,

所以,需要做一个策略,优先把资源让给查数,数据查完之后再去查页码。

限流

由于多线程取数据并没有从本质上提高数据库性能,所以必须针对大数据量实时统计排序分页查询做限流

我这里打个比方:食堂有6个窗口,物流团队吃饭要买6个菜,平均每买1个菜需要1分钟的时间,

如果派我一个人去一个窗口买的话需要6分钟的时间

假如派6个人分别去6个窗口买这6个菜,只需要1分钟的时间

但是,如果除了物流团队,再来其他5个团队呢,也就是说6个团队每个团队买6个菜共买36个菜,

这样子有的团队先买完,有的团队后买完,但平均时间还是6分钟。本质上没有变化。

所以,对于特定的查询条件,必须进行限流。让每分钟至多有6个团队买菜,这样子能使得情况变得不至于太糟糕。

从根本上改变现状

这一点从目前来看只能是展望了,比如mysql数据库换更为强大的oracle数据库,

或更换InnoDb引擎为其他,或更换SATA硬盘为SSD 。。。。。。

从实践效果来看,优化后的效果是很明显的。

相同的查询条件,原来一个页面查询时间由于超过60秒超时了,根据1-6点建议优化之后,查询时间变为2秒至35秒之间。

分不同的类型,可按以下三种方式查询:

一、查看MySQL数据库服务器和数据库MySQL字符集。

命令:

1mysql> show variables like '%char%';

二、查看MySQL数据表(table)的MySQL字符集。

命令:

1mysql> show table status from sqlstudy_db like '%countries%';

三、查看MySQL数据列(column)的MySQL字符集。

命令:

1mysql> show full columns from countries;

mysql创建数据库一般使用的

字符集

为UTF-8,但具体的要根据实际情况进行选择。

工具:mysql56,Navicat

Premium

步骤:

1、打开Navicat

Premium,双击左侧服务器的

树形结构

,连接到服务器,这里以

localhost

为例。

2、在localhost处点右键,选择“新建数据库”。

3、d出窗口中,填写新建的数据库名字,这里填写的是“badkano”,然后选择字符集,下拉列表,选择UTF-8,排序规则可不填,然后点“确定”按钮。

4、由图可见,badkano数据库创建成功。

以上就是关于怎么给mysql设置默认字符集和排序规则全部的内容,包括:怎么给mysql设置默认字符集和排序规则、关于mysql数据库里面数据类型number的问题、如何设置mysql数据库为utf-8编码等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

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

原文地址: https://outofmemory.cn/sjk/9508380.html

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

发表评论

登录后才能评论

评论列表(0条)

保存