存储引擎决定了表的类型，而表内存放的数据也要有不同的类型，每种数据类型都有自己的宽度，但宽度是可选的
已经知道,对于int了tinyint了这些MySql类型,后面那个4或者11没啥实际意义,只是说(当位数不足时)前面填充多少个0,然后使之变为4位或者11位,对这个类型的字段实际能存的长度没啥影响.
一 介绍 存储引擎决定了表的类型，而表内存放的数据也要有不同的类型，每种数据类型都有自己的宽度，但宽度是可选的 详细参考： http://www.runoob.com/mysql/mysql-data-types.html http://dev.mysql.com/doc/refman/5.7/en/data-type-overview.html mysql常用数据类型概览 #1. 数字： 整型：tinyinit int bigint 小数： float ：在位数比较短的
MySQL不同存储引擎可能会有不同。下面的内容以InnoDB为主。 选择数据类型的步骤 确定合适的大类型：数字、字符串、时间、二进制 确定具体的类型：有无符号、取值范围、变长定长等。 整数类型 类型 字节数 范围 TNIYINT 1 -128~127 SMALLINT 2 -32767~32768 MEDIUMINT 3 -8388608~8388607 INT 4 -2147483648~2147483647 BIGINT 8 -9223372036854775808~922337203685477
1.b+树只有叶子节点存数据 b树是每个节点都存数据 在相同数据量下b树的高度更高,所以查询效率更低
一 介绍 存储引擎决定了表的类型，而表内存放的数据也要有不同的类型，每种数据类型都有自己的宽度，但宽度是可选的 详细参考： http://www.runoob.com/mysql/mysql-data-types.html http://dev.mysql.com/doc/refman/5.7/en/data-type-overview.html mysql数据类型概览 #1. 数字： 整型：tinyinit int bigint 小数： float ：在位数比较短的情况
TiFlash是TiDB生态组件之一，专门解决OLAP场景。借助ClickHouse实现高效的列式计算。
我们不推荐使用非严格模式下建立table，因为它会可能造成数据丢失的情况，所以我们必须在5.6版本中将mysql设置为严格模式。
mysql是关系型数据库，主要用于存放持久化数据，将数据存储在硬盘中，读取速度较慢。
1、假如只需要存0~255之间的数，无负数，应使用tinyint unsigned(保证最小数据类型) 2、如果长度不可定，如varchar，应该选择一个你认为不会超过范围的最小类型 比如: varchar(20)，可以存20个中文、英文、符号，不要无脑使用varchar(150) 3、整形比字符操作代价更低。比如应该使用MySQL内建的类型(date/time/datetime)而不是字符串来存储日期和时间 4、应该使用整形存储IP地址，而不是字符串 5、尽量避免使用NULL，通常情况下最好指定列为NOT NULL，除非真的要存储NULL值 6、DATETIME和TIMESTAMP列都可以存储相同类型的数据：时间和日期，且精确到秒。然而TIMESTAMP只使用DATETIME一半的内存空间，并且会根据时区变化，具有特殊的自动更新能力。另一方面，TIMESTAMP允许的时间范围要小得多，有时候它的特殊能力会变成障碍
首先数据选择有几个简单原则： 更小的通常更好。一般情况下，应该尽量使用可以正确存储数据的最小数据类型。例如只需要存 0~200，tinyint unsigned 更好。更小的数据类型通常更快，因为它们占用更少的磁盘、内存和 CPU 缓存，并且处理时需要的 CPU 周期也更少。 简单就好。简单数据类型的操作通常需要更少的 CPU 周期。例如，整型比字符操作代价更低，因为字符集和校对规则（排序规则）使字符比较 比 整型比较更复杂。这里有两个例子：一个是应该使用 MySQL 内建的类型（date, time, d
数值类型中又可以分为整型、浮点型，或者可以说为严格数值数据类型以及近似数值数据类型
一觉醒来，就发现有人给我微信上发消息，通知我说数据库创业圈子里，又出来一件牛逼大了的事情。 我一看，原来是PingCAP放大招了，PingCAP在美国加州硅谷从甲骨文公司挖了Sunny Bains入职。 这位Sunny Bains的背景，大体上就是在印度上完了中学，在澳大利亚墨尔本上完了本科，然后在澳洲的CTI工作了一段时间，之后就来到美国的甲骨文公司了。 他在甲骨文公司从2006年一直干到现在，最近加盟PingCAP。之前在甲骨文负责的就是InnoDB。坦白讲，我对这位Sunny Bains大神不熟。恕我
量化回测，苦于MySQL久矣，特别是进行股票日内因子构建分析或全市场因子测试的时候，每当按下回车时，MySQL就跟丢了魂一样，查询费时，大吞吐量读取也非常耗时。虽然MySQL的优化技巧足够写一本书，但这些都需要交给专业的DB工程师去做，量化打工人没有能力更没有时间倒腾这些。那有没有省时省力，高效存储股票行情数据的解决办法呢。带着这个问题，编辑部简单的搜索了一下，总体分为几个方案：
其实很早以前我就在《高性能MySQL第三版》中看过IP地址属于特殊类型数据，应转为整数存储。
日期算是我们在日常开发中经常用到的数据类型，一般来说一张表都有 createTime 和 updateTime 字段，MySQL 中针对日期也提供了很多种不同的数据类型，如： datetime timestamp int 等等。甚至也有人直接将日期存为字符串的。 那么到底该用哪种类型来保存日期呢？ 1. 字符串 在这些类型中，首先应该排除掉的就是字符串了，很多新手小伙伴爱用字符串存储日期，但实际上这并不是一个很好的方案。 使用字符串存储日期，第一个显而易见的问题就是无法使用 MySQL 中提供的日期函数，
因为 InnoDB 在存储数据的时候，更加安全，所以默认的存储引擎是InnoDB(虽然 MyISAM 比 InnoDB 快)
看完这篇文章，你能搞清楚以下问题： 1、varchar(100)和varchar(10)的区别在哪里？ 2、varchar能存多少汉字、数字？ 3、varchar的最大长度是多少呢？ 4、字符、字节、位，之间的关系？ 5、mysql字段类型存储需要多少字节？ 接下来请仔细看，整理不易啊。 1、varchar(100)和varchar(10)的区别在哪里？ 一般初学会认为，二者占用的空间是一样的。比如说我存储5个char，二者都是实际占用了5个char了【不准确的想法：varchar在实际存储的时候会多一个b
在mysql5.5版本之后新增了performance_schema的数据库用于监视数据库性能，该数据库中表的引擎都是performance_schema。PS数据库默认是关闭的，其中的表都是内存表，不存储在磁盘中，在服务器重启后数据消失。在数据文件performance_schema目录下只有表结构文件不存在数据文件，对这些表的改变不会记录到binlog中。数据收集是通过修改服务器源代码来实现的，不存在与PS相关联的单独线程。PS数据库消耗很少的性能，官方文档介绍即使将PS中所有监控项开启也不会对mysql server性能造成太大影响。
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)
关系型数据库：数据库中的数据能产生关系，表与表之间有关联。特点：安全（数据会不会丢失）、存在关系。 例如：Mysql、Sql Server、Oracle等。 非关系型数据库：没有关系，单纯存数据。特定：快、不安全。 例如：MongoDB、Redis等。
最近一朋友做社区重构，社区主要功能有发帖、回帖、查看帖子详情，详情页按不同条件展示回帖（除了预先定义的顺序外，可能每个用户看到的顺序都不一样，组合超过100个），大概的效果如下：
在 上篇关于 TiFlash 的文章 发布后，我们收到了很多伙伴们的反馈，大家有各种各样的疑问，包括 TiFlash 是不是 T + 1 列存数据库？为啥实时写入也很快？读压力大怎么办？节点挂了怎么办？业务怎么接入？……今天我们就来详细回复一下大家的问题，希望能对大家理解和实践 TiFlash 有所帮助。
MySQL 中常用的两种时间储存类型分别是datetime和 timestamp。如何在它们之间选择是建表时必要的考虑。下面就谈谈他们的区别和怎么选择。
其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！
摘要：MySQL在充分利用多核计算资源方面比较欠缺，无法同时满足在线业务和分析型业务的客户需求，而单独部署一套专用的分析型数据库意味着额外的成本和复杂的数据链路。本次主题将介绍腾讯云数据库为满足此类场景而在HTAP for MySQL产品方面进行的尝试。
如果是GBK编码，则一个中文汉字占2个字节，英文占1个字节 如果是UTF8编码，则一个中文汉字占3个字节，而英文字母占1字节。 比如定义某个字段数据类型为：varchar(32)，表示这个可以存储 32 个字符，此时表示的是字符，所以跟中英文无关，也就是该字段可以存储 32 个中文，或者是 32 个英文，或者是 32 个中文和英文的混搭都行。但如果字符数超过 32 个的话就会报错。
说一下mysql比较宏观的面试，具体咋写sql的这里就不过多举例了。后面我还会给出一个关于mysql面试优化的试题，这里主要说的索引和B+Tree结构，很少提到我们的集群配置优化方案。
「 第一部分 概述 」 数据库中存在两种典型的业务访问场景，一种以在线事务处理为主，称为OLTP（On-Line Transaction Processing）；另一种以在线分析处理为主，称为OLAP（On-Line Analytical Processing）。下面具体介绍他们的区别。 1.1 OLTP OLTP业务的主要特点是有较多的增删改查操作，并且在大部分业务中，写相对于读的比例还很高。并发的事务数较多，而且事务的响应时间要求比较高。此外，每个增删改语句通常只操作少数几行数据；每个查询语句通常也只
关于这些查找结果的演示推荐：<https://www.cs.usfca.edu/~galles/visualization/Algorithms.html>
我们常见的数据库性能优化就是SQL语句优化，确实SQL优化是开发者接触到最多的也是最常有的优化手段。作为开发人员我们接触最多的也就是SQL语句的优化，SQL语句的优化除了调整SQL语句外更多的是通过添加索引来加速查询，表结构(合理设计字段、拆分字段到其它表、分表等)的优化也是我们优化的主要手段。
本文是MySQL创始人Monty在5月30日"腾讯云CDB/CynosDB技术揭秘"系列直播中的分享实录。 ---- 大家好，我是MariaDB的 Michael Widenius，我们今天来简单的聊下MariaDB10.5新特性和即将要做的事情。10.5已经是RC了，应该是下周四GA，所以非常近了。 Monty全程分享视频 从我个人加到MariaDB的特性开始，这也是我现在依然写代码的地方，差不多我花了我至少一半的时间在做这里。实际上在COVID-19期间，我花了90%的时间在做这里，这还是很好的。
在MySQL数据类型设置方面，尽量采用更小的数据类型，因为它们占用的存储空间更小，通常有更好的性能，花费更少的硬件资源。并且，尽量把字段定义为NOT NULL，避免使用NULL。
这篇文章主要讲述了在单机数据库环境下如何进行优化，包括表结构优化、字符集选择、字段设计、索引创建等方面，同时指出了一些注意事项。
大家好我是北哥，今天整理了MySQL索引相关的知识点及面试常见问题及答案，分享给大家。 以下问题及答案没有特殊说明默认都是针对InnoDB存储引擎，如有不对的地方可以留言讨论哦~ 什么是索引？
mysql存储引擎有以下几种类型：myisam、innodb、csv、memory等，当然常用的还是myisam和innodb
这个问题可能比较抽象，如果对MySQL索引结构不理解的人来说，可能蒙，所以建议先去看看索引结构再来看这个问题。MySQL 选择将节点大小设置为 16KB 而不是更大的原因，主要是为了在内存管理、性能、磁盘 I/O 效率、适应性和兼容性之间取得平衡。本文将从讲解页的结构开始，然后分析为什么MySQL为什么把节点大小设置为16K，而不是更大?
随着闲鱼业务的发展，用户规模达到数亿级，用户维度的数据指标，达到上百个之多。如何从亿级别的数据中，快速筛选出符合期望的用户人群，进行精细化人群运营，是技术需要解决的问题。业界的很多方案常常需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法，从亿级别数据中，任意组合查询条件，筛选需要的数据，做到毫秒级返回。
老妈：还吴京八经的，特么牛魔王去了都得耕地，唐三藏去了都得打出舍利，孙悟空去了都得演大马戏
这里是为后续的mysql调优做准备，要像做到mysql调优，索引很关键，理解索引结构，页结构，对于调优来说是很重要的基础。
>- ENUM和CHAR(VARCHAR)类型关联查询，会慢一些，因此，假如预先知道某列需要与CHAR类型关联，那么就不应该将该列设置为ENUM类型 >- ENUM类型的列可有效缩小表所占的空间，书中写可缩小1/3
索引用于快速找出在某个列中有一特定值的行。不使用索引，MySQL必须从第1条记录开始然后读完整个表直到找出相关的行。表越大，花费的时间越多。如果表中查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要看所有数据。大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B树中存储。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。
索引用于快速找出在某个列中有一特定值的行。不使用索引，MySQL必须从第1条记录开始然后读完整个表直到找出相关的行。 表越大，花费的时间越多。如果表中查询的列有一个索引，MySQL能快速到达一个位置去搜寻到数据文件的中间，没有必要看所有数据。 大多数MySQL索引(PRIMARY KEY、UNIQUE、INDEX和FULLTEXT)在B树中存储。只是空间列类型的索引使用R-树，并且MEMORY表还支持hash索引。
我们都知道，MySQL中关于字符，有char和varchar两种常用的类型，可能在平时的使用过程中，大家不会去关心这两种类型的区别，只是会用就可以了，或者说看到过一些它们的区别，但是没有时间去测试，今天有时间了，我将这两种类型的具体情况实验一把，让大家直观感受下，纯属分享，大神请绕道。
ps：char(n) 和 varchar(n) 中括号中 n 代表字符的个数，并不代表字节个数，比如 CHAR(30) 就可以存储 30 个字符，超出报错
1、隔离级别有四种： READ UNCOMMITTED（未提交读），同事务中某个语句的修改，即使没有提交，对其他事务也是可见的。这个也叫脏读。 READ COMMITTED（提交读），另一个事务只能读到该事务已经提交的修改，是大多数据库默认的隔离级别。但是有下列问题，一个事务中两次读取同一个数据，由于这个数据可能被另一个事务提交了两次，所以会出现两次不同的结果，所以这个级别又叫做不可重复读。这里的不一样的数据包括虚读（两次结果不同）和幻读（出现新的或者缺少了某数据）。 REPEATABLE READ（可重复读），这个级别不允许脏读和不可重复读，比如MYSQL中通过MVCC来实现解决幻读问题。 SERIALIABLE（可串行化），这儿实现了读锁，级别最高。
有很长一段时间没有做PHP开发了，最近有做PHP开发的小伙伴在个人微信公众号后台留言，能够分享一些PHP有关的面试题。于是给安排上。
原本觉得mysql数据类型是非常简单并十分基础的知识，认为自己掌握的差不多了。但经过上一次的面试，才发现自己掌握的并不牢固，很多细节和原理并不知道。后来翻阅了《高性能mysql》这本书，仔细阅读了第四章Schema与数据类型优化。因此，写这篇文章记录和总结下，并加深理解。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
