如何才能使图形化管理MySQL更轻松(一)

如何才能使图形化管理MySQL更轻松(一),第1张

MySQL是一个真正的多用户 多线程SQL数据库服务器 是目前最流行的开放源码数据库服务器之一 来自MySQL项目的数据显示 目前MySQL用户已经达到 万个 大家熟知的 使用MySQL的Web站点包括Yahoo Finance Motorola NASA Silicon Graphics和Texas Instruments等 一般来说 用户以命令行的方式来使用MySQL 很多用户在Windows环境中一直使用图形用户界面(GUI)来 *** 作和管理数据库 对命令行方式可能不习惯 而很多新手更是觉得MySQL不容易掌握 为了方便用户对MySQL数据库进行管理 实际上早就已经有一些图形化用户管理的项目在进行中 它们是MySQL Control Center(MySQLCC) MySQLGUI和phpMyAdmin 此外 使用Red Hat自带的OpenOffice也可以完成对MySQL的图形化管理 安装MySQL 在安装 设置和应用图形化管理工具之前 首先要安装好MySQL服务器 使用以下命令查看本机是否安装了MySQL # rpm qa | grep mysqlmysql server a mysql a 本文所有例子均在Red Hat 中实现 在Red Hat 中 可以通过 软件包管理 程序来直接安装MySQL 具体方法是先在 添加或删除软件包 界面选中 SQL数据库服务器 并在细节中选中 mysql server MySQL服务器和相关的文件 然后插入第二张光盘 选择更新即可 也可以通过直接从光盘上使用rpm命令进行安装 因为MySQL服务器需要Perl语言的支持才能正常运行 所以在采用后一种安装方法时 安装MySQL前需要先安装Perl语言及相关软件包 安装完成后 使用以下命令启动MySQL服务器 #service mysqld startMySQL在安装完成后 预定义了一个超级用户root 口令为空 任何用户均可以从MySQL服务器本地使用该用户连接MySQL数据库进行 *** 作 显然这非常不安全 所以MySQL启动之后 应该立即设置root密码 设置方法如下 #mysqladmin password ylgui 这样就设置了一个新的密码 ylgui MySQL服务器是否已经正常运行?可以通过启用客户端程序mysql进行查看 这里要使用到上面设置的密码 # mysql u root pylguiWele to the MySQL monitor Commands end with or \g Your MySQL connection id is to server version: Type helpor \h for help Type \c to clear the buffer 注意 参数p与密码之间没有空格 屏幕会显示目前都有哪些数据库 mysql>show databases+ +| Database |+ +| mysql|| test |+ + rows in set ( sec)可以看到MySQL数据库服务器里有两个数据库 分别是mysql和test 这表明该数据库服务器已经正确安装 并已经正常启动 下面就分别看看四种MySQL GUI解决方案的安装 设置和使用情况 MySQL Control CenterMySQLCC是一个功能齐全的 基于GUI的MySQL客户端程序 可以跨平台 *** 作 它提供多种风格的用户界面 支持简体中文 易于 *** 作 某些 *** 作界面与SQL Server数据库系统的客户端工具—— 企业管理器 非常相似 因此 无论在功能上还是在界面上 MySQLCC都可以与商业数据库所提供的 基于GUI的客户端程序相媲美 该项目的开发一直非常活跃 .下载可从下载该软件 写作本文时 该软件的较新版本是 并有两个不同版本 一个是针对glibc 的 另一个是针对glibc 的 下载前 需要先查看本机glibc的版本号 # rpm qa |grep glibcglibc kernheaders glibc mon glibc devel glibc 由上可知Red Hat 中所安装的是glibc 下载的软件包文件名为mysqlcc linux glibc tar gz .安装先将文件移至/usr/local目录下 然后切换至想要安装该软件的目录 #mv mysqlcc linux glibc tar gz /usr/local#cd /usr/local解开软件包 并创建安装路径 #tar xvzf /usr/local/mysqlcc linux glibc tar gz#ln s mysqlcc linux glibc mysqlcc第一个命令tar会创建一个名为mysqlcc linux glibc 的目录 第二个命令ln则会创建一个符号链接 这样做的目的是为了让每次进入安装目录时更加容易 只需使用命令cd/usr/local/mysqlcc即可进入安装目录 进入安装目录后 执行 /mysqlcc启动该程序 界面如图 所示 educity cn/img_ / / / jpg >图 MySQLCC用户界面 .设置启动MySQLCC后 选择 Option 选单中的 General 然后将 Language 选项设置为 Simplified Chinese (简体中文) 注意 在默认情况下 应用程序使用的字体并不能正确显示中文 所以还应该将其更改为可以正确显示中文的字体 方法是依次选择 Option→Fonts→Application Font 然后在d出的界面中进行选择 这里将其选为Zysong 选择结尾为GB的字体也可以正确显示中文 选择完成后 重新启动MySQLCC 即可进入具有中文字体显示的界面 如图 所示 educity cn/img_ / / / jpg>图 设置后的中文界面 由图 和图 可以看到 启动MySQLCC时 会d出设置 注册服务器 的界面 在该界面输入名称为MySQL 主机名为 用户名为root 密码为上文所设置的ylgui 其它选项不用更改 单击 添加 即可将新建的连接添加至连接列表中 如图 所示 educity cn/img_ / / / jpg>图 添加新建的连接 选中新建的连接 然后单击 连接 按钮 即可完成连接 如图 所示 educity cn/img_ / / / jpg>图 连接到MySQL数据库服务器 . *** 作数据库 设置好MySQLCC后就可以应用该管理工具来对数据库进行 *** 作了 ( ) 创建/删除数据库 在左边列表中的 数据库 项上单击右键 选择 新建数据库 然后在d出的对话框中输入数据库名称 mydatabase 这时 数据库 项目下就会显示名为 mydatabase 的数据库 如果要删除新建的数据库 可以直接在该数据库上单击右键 然后选择 丢弃数据库 即可完成删除 ( ) 新建/删除表 双击 mydatabase 其下方会显示 表 的子项 在该子项目上单击右键 选择 新建数据表 这时会d出创建表的界面 如图 所示 为简单起见 这里只为该表设置了四个字段 NO name sex birthday 单击保存 将该表保存为mytable educity cn/img_ / / / jpg >图 新建表 要删除数据库中的表 直接在该表上单击右键 然后选择 丢弃表 即可完成删除 ( ) 更改表结构 要编辑表结构 可直接在表上单击右键 选择 编辑表 可以对表进行各种更改 包括添加/删除字体 更改字段属性 创建索引 更改表属性等 *** 作 ( ) 输入数据 要向该表输入数据 直接在该表上双击左键 会打开如图 所示的查询窗口 在该窗口中 可以对表进行各种 *** 作 比如要向表中添加/删除记录 只需单击工具栏上的插入/删除记录即可 educity cn/img_ / / / jpg >图 向表中输入记录 在图 所示界面中 还可以非常方便地使用SQL语句对表进行 *** 作 方法是单击工具栏上的SQL图标 然后在查询框中输入SQL语句 单击工具栏上的 执行 即可 如果对查询语句不熟 也可以直接在工具栏上单击 查询类型 按键 并在下拉列表中选择常用的查询语句 如图 所示educity cn/img_ / / / jpg>图 使用SQL语句 lishixinzhi/Article/program/MySQL/201311/29323

在开始演示之前,我们先介绍下两个概念。

概念一,数据的可选择性基数,也就是常说的cardinality值。

查询优化器在生成各种执行计划之前,得先从统计信息中取得相关数据,这样才能估算每步 *** 作所涉及到的记录数,而这个相关数据就是cardinality。简单来说,就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录,其中一列为f1。f1中唯一值的个数可以是100个,也可以是1个,当然也可以是1到100之间的任何一个数字。这里唯一值越的多少,就是这个列的可选择基数。

那看到这里我们就明白了,为什么要在基数高的字段上建立索引,而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面,至于更深入的探讨就不在我这篇探讨的范围了。

概念二,关于HINT的使用。

这里我来说下HINT是什么,在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作,使她生成最优的执行计划。一般来说,优化器的执行计划都是最优化的,不过在某些特定场景下,执行计划可能不是最优化。

比如:表t1经过大量的频繁更新 *** 作,(UPDATE,DELETE,INSERT),cardinality已经很不准确了,这时候刚好执行了一条SQL,那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢?

来看下具体演示

譬如,以下两条SQL,

A:

select * from t1 where f1 = 20

B:

select * from t1 where f1 = 30

如果f1的值刚好频繁更新的值为30,并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等,那么对这两条语句来说,可能不准确的就是B了。

这里顺带说下,MySQL提供了自动更新和手动更新表cardinality值的方法,因篇幅有限,需要的可以查阅手册。

那回到正题上,MySQL 8.0 带来了几个HINT,我今天就举个index_merge的例子。

示例表结构:

mysql>desc t1+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (0.00 sec)

表记录数:

mysql>select count(*) from t1+----------+| count(*) |+----------+|    32768 |+----------+1 row in set (0.01 sec)

这里我们两条经典的SQL:

SQL C:

select * from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2

SQL D:

select * from t1 where rank1 =100  and rank2 =100  and rank3 =100

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然,没有用到任何索引,扫描的行数为32034,cost为3243.65。

mysql>explain  format=json select * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "3243.65"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "0.36",      "cost_info": {        "read_cost": "3232.07",        "eval_cost": "11.58",        "prefix_cost": "3243.65",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)

我们加上hint给相同的查询,再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103,cost为441.09,明显比之前的快了好几倍。

mysql>explain  format=json select /*+ index_merge(t1) */ * from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "441.09"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "100.00",      "cost_info": {        "read_cost": "330.79",        "eval_cost": "110.30",        "prefix_cost": "441.09",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank1` = 1) or (`ytt`.`t1`.`rank2` = 2) or (`ytt`.`t1`.`rank3` = 2))"    }  }}1 row in set, 1 warning (0.00 sec)

我们再看下SQL D的计划:

不加HINT,

mysql>explain format=json select * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "534.34"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "0.07",      "cost_info": {        "read_cost": "478.84",        "eval_cost": "0.04",        "prefix_cost": "534.34",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)

加了HINT,

mysql>explain format=json select /*+ index_merge(t1)*/ * from t1 where rank1 =100 and rank2 =100 and rank3 =100\G*************************** 1. row ***************************EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "5.23"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "100.00",      "cost_info": {        "read_cost": "5.13",        "eval_cost": "0.10",        "prefix_cost": "5.23",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt`.`t1`.`rank3` = 100) and (`ytt`.`t1`.`rank2` = 100) and (`ytt`.`t1`.`rank1` = 100))"    }  }}1 row in set, 1 warning (0.00 sec)

对比下以上两个,加了HINT的比不加HINT的cost小了100倍。

总结下,就是说表的cardinality值影响这张的查询计划,如果这个值没有正常更新的话,就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

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总用量 3.0G3541825 861M -rw-r----- 1 mysql mysql 860M 12月 10 11:36 t1.ibd3541820 989M -rw-r----- 1 mysql mysql 988M 12月 10 11:38 t2.ibd3541823 1.2G -rw-r----- 1 mysql mysql 1.2G 12月 10 11:39 t3.ibd

二、浮点数 / 定点数先说 浮点数,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 (0.03 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 (0.02 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:01.000000' 到 '2038-01-19 03:14:07.999999';datetime 取值范围为 '1000-01-01 00:00:00.000000' 到 '9999-12-31 23:59:59.999999'。

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

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)) virtualQuery OK, 1 row affected (2.46 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 (0.02 sec)

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

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

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

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

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

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

把 c1 的数据全部插入 c2。

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

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

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

七、枚举类型

枚举类型,也即 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 (0.03 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 (0.02 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_numberQuery OK, 128 rows affected (0.01 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 (0.00 sec)

总结

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


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

原文地址: https://outofmemory.cn/zaji/6133842.html

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

发表评论

登录后才能评论

评论列表(0条)

保存