AI 助理
备案控制台
开发者社区 数据库 文章 正文

MYSQL INNODB主键使用varchar和int的区别

2017-07-11 2234
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL，集群系列 2核4GB
推荐场景：
搭建个人博客
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
RDS MySQL Serverless 高可用系列，价值2615元额度，1个月
简介： 原创，如果有误请指出 今天同事讨论关于主键使用varchar和int的区别。 我现在总结的3个问题： 1、tablespace中空间浪费    当然我们知道使用varchar可能会导致辅助索引比较大，因为用到varchar可能存储的字符较多，同时    在行头也存在一个可变字段字符区域(1-2)字节    而辅助索引叶子结点毕竟都存储了主键值，这样至少会多varchar数据字节数量+1(或者2) 字节- 4(int)字节空间。
原创，如果有误请指出

今天同事讨论关于主键使用varchar和int的区别。

我现在总结的3个问题：
1、tablespace中空间浪费
   当然我们知道使用varchar可能会导致辅助索引比较大，因为用到varchar可能存储的字符较多，同时
   在行头也存在一个可变字段字符区域(1-2)字节
   而辅助索引叶子结点毕竟都存储了主键值，这样至少会多varchar数据字节数量+1(或者2) 字节- 4(int)字节空间。
   如果辅助索引比较多空间浪费是可想而知的。
2、辅助索引B+树扫描性能
    由于辅助索引B+树的空间要求更大，虽然在B+树层次一般都是3层-4层，索引单值定位I/O消耗并不明显，如果涉及到
    范围查询(比如PAGE_CUR_G),需要访问的块就更多，同时比如例如辅助索引的using index，需要访问的块自然
    更多
3、比较更加复杂
   innodb 在进行元组比较的时候，不管是DML，select都会涉及到元组的比较，同时回表的时候也涉及
   到比较操作。而varchar类型的比较比int类型更为复杂一些。
那么我们就来分析第三个问题，第一个问题和第二个问题是显而易见的。
我这里数据库字符集为latin1\latin1_swedish_ci

其实在innodb底层进行比较的时候都调用cmp_data这个函数
在innodb中有自己的定义的数据类型如下：

点击(此处)折叠或打开

  1. /*-------------------------------------------*/
  2. /* The 'MAIN TYPE' of a column */
  3. #define DATA_MISSING    0    /* missing column */
  4. #define    DATA_VARCHAR    1    /* character varying of the
  5. latin1_swedish_ci charset-collation; note
  6. that the MySQL format for this, DATA_BINARY,
  7. DATA_VARMYSQL, is also affected by whether the
  8. 'precise type' contains
  9. DATA_MYSQL_TRUE_VARCHAR */
  10. #define DATA_CHAR    2    /* fixed length character of the
  11. latin1_swedish_ci charset-collation */
  12. #define DATA_FIXBINARY    3    /* binary string of fixed length */
  13. #define DATA_BINARY    4    /* binary string */
  14. #define DATA_BLOB    5    /* binary large object, or a TEXT type;
  15. if prtype & DATA_BINARY_TYPE == 0, then this is
  16. actually a TEXT column (or a BLOB created
  17. with < 4.0.14; since column prefix indexes
  18. came only in 4.0.14, the missing flag in BLOBs
  19. created before that does not cause any harm) */
  20. #define    DATA_INT    6    /* integer: can be any size 1 - 8 bytes */
  21. #define    DATA_SYS_CHILD    7    /* address of the child page in node pointer */
  22. #define    DATA_SYS    8    /* system column */

我们熟悉的int类型属于DATA_INT而varchar属于DATA_VARCHAR，rowid属于DATA_SYS
在函数cmp_data根据各种类型的不同进行了不同比较的方式，这里就将int和varchar
判断的方式进行说明：
1、innodb int类型比较
实际上是在cmp_data中进行了大概的方式如下

点击(此处)折叠或打开

  1. if (len) {
  2. #if defined __i386__ || defined __x86_64__ || defined _M_IX86 || defined _M_X64
  3. /* Compare the first bytes with a loop to avoid the call
  4. overhead of memcmp(). On x86 and x86-64, the GCC built-in
  5. (repz cmpsb) seems to be very slow, so we will be calling the
  6. libc version. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052
  7. tracks the slowness of the GCC built-in memcmp().


  10. We compare up to the first 4..7 bytes with the loop.
  11. The (len & 3) is used for "normalizing" or
  12. "quantizing" the len parameter for the memcmp() call,
  13. in case the whole prefix is equal. On x86 and x86-64,
  14. the GNU libc memcmp() of equal strings is faster with
  15. len=4 than with len=3.


  18. On other architectures than the IA32 or AMD64, there could
  19. be a built-in memcmp() that is faster than the loop.
  20. We only use the loop where we know that it can improve
  21. the performance. */
  22. for (ulint i = 4 + (len & 3); i > 0; i--) {
  23. cmp = int(*data1++) - int(*data2++);
  24. if (cmp) {
  25. return(cmp);
  26. }


  29. if (!--len) {
  30. break;
  31. }
  32. }
  33. my_strnncollsp_simple


  36. if (len) {
  37. #endif /* IA32 or AMD64 */
  38. cmp = memcmp(data1, data2, len);


  41. if (cmp) {
  42. return(cmp);
  43. }


  46. data1 += len;
  47. data2 += len;
  48. #if defined __i386__ || defined __x86_64__ || defined _M_IX86 || defined _M_X64
  49. }
  50. #endif /* IA32 or AMD64 */
  51. }


  54. cmp = (int) (len1 - len2);


  57. if (!cmp || pad == ULINT_UNDEFINED) {
  58. return(cmp);
  59. }
可以看到整个方式比较简洁，对于我们常用的x86_64模型并没有直接使用memcpy进行而是
进行了优化在注释中也有说明，才出现了for (ulint i = 4 + (len & 3); i > 0; i--)
部分，如果是IA32 or AMD64则直接使用memcpy进行比较。感兴趣的可以仔细阅读一下

2、innodb varchar类型比较
实际上这个比较会通过cmp_data->cmp_whole_field->my_strnncollsp_simple调用最终调用
my_strnncollsp_simple完成，而比如order by 会调用my_strnxfrm_simple他们都在一个
文件中。
下面是整个my_strnncollsp_simple函数


点击(此处)折叠或打开

  1. /*
  2.   Compare strings, discarding end space


  5.   SYNOPSIS
  6.     my_strnncollsp_simple()
  7.     cs    character set handler
  8.     a    First string to compare
  9.     a_length    Length of 'a'
  10.     b    Second string to compare
  11.     b_length    Length of 'b'
  12.     diff_if_only_endspace_difference
  13.        Set to 1 if the strings should be regarded as different
  14.                         if they only difference in end space


  17.   IMPLEMENTATION
  18.     If one string is shorter as the other, then we space extend the other
  19.     so that the strings have equal length.


  22.     This will ensure that the following things hold:


  25.     "a" == "a "
  26.     "a\0" < "a"
  27.     "a\0" < "a "


  30.   RETURN
  31.     < 0    a < b
  32.     = 0    a == b
  33.     > 0    a > b
  34. */


  37. int my_strnncollsp_simple(const CHARSET_INFO *cs, const uchar *a,
  38.                           size_t a_length, const uchar *b, size_t b_length,
  39.                           my_bool diff_if_only_endspace_difference)
  40. {
  41.   const uchar *map= cs->sort_order, *end;
  42.   size_t length;
  43.   int res;


  46. #ifndef VARCHAR_WITH_DIFF_ENDSPACE_ARE_DIFFERENT_FOR_UNIQUE
  47.   diff_if_only_endspace_difference= 0;
  48. #endif


  51.   end= a + (length= MY_MIN(a_length, b_length));
  52.   while (a < end)
  53.   {
  54.     if (map[*a++] != map[*b++])
  55.       return ((int) map[a[-1]] - (int) map[b[-1]]);
  56.   }
  57.   res= 0;
  58.   if (a_length != b_length)
  59.   {
  60.     int swap= 1;
  61.     if (diff_if_only_endspace_difference)
  62.       res= 1; /* Assume 'a' is bigger */
  63.     /*
  64.       Check the next not space character of the longer key. If it's < ' ',
  65.       then it's smaller than the other key.
  66.     */
  67.     if (a_length < b_length)
  68.     {
  69.       /* put shorter key in s */
  70.       a_length= b_length;
  71.       a= b;
  72.       swap= -1; /* swap sign of result */
  73.       res= -res;
  74.     }
  75.     for (end= a + a_length-length; a < end ; a++)
  76.     {
  77.       if (map[*a] != map[' '])
  78. return (map[*a] < map[' ']) ? -swap : swap;
  79.     }
  80.   }
  81.   return res;
  82. }
其中*map= cs->sort_order比较关键这是内存中已经存储好的字符集的顺序，
循环进行
map[*a++] != map[*b++]
*a++和*b++ 会得到的字符集编码，然后在整个排序好的字符数组中找，
则得到了实际字符集编码进行比较，不管是比较的复杂度还是需要比较的
长度 varchar很可能都远远大于int类型，下面是打印cs->sort_order这片
内存区域前128字节得到的结果，
(gdb) x/128bx 0x258b000
0x258b000 :          0x00    0x01    0x02    0x03    0x04    0x05    0x06    0x07
0x258b008 :        0x08    0x09    0x0a    0x0b    0x0c    0x0d    0x0e    0x0f
0x258b010 :       0x10    0x11    0x12    0x13    0x14    0x15    0x16    0x17
0x258b018 :       0x18    0x19    0x1a    0x1b    0x1c    0x1d    0x1e    0x1f
0x258b020 :       0x20    0x21    0x22    0x23    0x24    0x25    0x26    0x27
0x258b028 :       0x28    0x29    0x2a    0x2b    0x2c    0x2d    0x2e    0x2f
0x258b030 :       0x30    0x31    0x32    0x33    0x34    0x35    0x36    0x37
0x258b038 :       0x38    0x39    0x3a    0x3b    0x3c    0x3d    0x3e    0x3f
0x258b040 :       0x40    0x41    0x42    0x43    0x44    0x45    0x46    0x47
0x258b048 :       0x48    0x49    0x4a    0x4b    0x4c    0x4d    0x4e    0x4f
0x258b050 :       0x50    0x51    0x52    0x53    0x54    0x55    0x56    0x57
0x258b058 :       0x58    0x59    0x5a    0x5b    0x5c    0x5d    0x5e    0x5f
0x258b060 :       0x60    0x41    0x42    0x43    0x44    0x45    0x46    0x47
0x258b068 :      0x48    0x49    0x4a    0x4b    0x4c    0x4d    0x4e    0x4f
0x258b070 :      0x50    0x51    0x52    0x53    0x54    0x55    0x56    0x57
0x258b078 :      0x58    0x59    0x5a    0x7b    0x7c    0x7d    0x7e    0x7f
而从内存的地址0x258b000我们也能看到他确实是存在于堆内存空间中，它是一片堆内存区域。

下面是varchar比较的调用栈帧以备后用

点击(此处)折叠或打开

  1. #0 my_strnncollsp_simple (cs=0x2d4b9c0, a=0x7fff57a71f93 "gaopeng", a_length=7, b=0x7fffbd7e807f "gaopeng", b_length=7, diff_if_only_endspace_difference=0 '\000')
  2.     at /root/mysql5.7.14/percona-server-5.7.14-7/strings/ctype-simple.c:165
  3. #1 0x0000000001ab8ec2 in cmp_whole_field (mtype=1, prtype=524303, a=0x7fff57a71f93 "gaopeng", a_length=7, b=0x7fffbd7e807f "gaopeng", b_length=7)
  4.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/rem/rem0cmp.cc:374
  5. #2 0x0000000001aba827 in cmp_data (mtype=1, prtype=524303, data1=0x7fff57a71f93 "gaopeng", len1=7, data2=0x7fffbd7e807f "gaopeng", len2=7)
  6.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/rem/rem0cmp.cc:468
  7. #3 0x0000000001ab9a05 in cmp_dtuple_rec_with_match_bytes (dtuple=0x7fff48ed3280, rec=0x7fffbd7e807f "gaopeng", index=0x7fff48ec78a0, offsets=0x7fff57a6bc50,
  8.     matched_fields=0x7fff57a6bf80, matched_bytes=0x7fff57a6bf78) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/rem/rem0cmp.cc:880
  9. #4 0x0000000001a87fe2 in page_cur_search_with_match_bytes (block=0x7fffbcceafc0, index=0x7fff48ec78a0, tuple=0x7fff48ed3280, mode=PAGE_CUR_GE,
  10.     iup_matched_fields=0x7fff57a6cdf8, iup_matched_bytes=0x7fff57a6cdf0, ilow_matched_fields=0x7fff57a6cde8, ilow_matched_bytes=0x7fff57a6cde0, cursor=0x7fff57a713f8)
  11.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/page/page0cur.cc:850
  12. #5 0x0000000001c17a3e in btr_cur_search_to_nth_level (index=0x7fff48ec78a0, level=0, tuple=0x7fff48ed3280, mode=PAGE_CUR_GE, latch_mode=1, cursor=0x7fff57a713f0,
  13.     has_search_latch=0, file=0x2336938 "/root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/btr/btr0cur.cc", line=5744, mtr=0x7fff57a70ee0)
  14.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/btr/btr0cur.cc:1478
  15. #6 0x0000000001c222bf in btr_estimate_n_rows_in_range_low (index=0x7fff48ec78a0, tuple1=0x7fff48ed3280, mode1=PAGE_CUR_GE, tuple2=0x7fff48ed32e0, mode2=PAGE_CUR_G,
  16.     nth_attempt=1) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/btr/btr0cur.cc:5744
  17. #7 0x0000000001c22a09 in btr_estimate_n_rows_in_range (index=0x7fff48ec78a0, tuple1=0x7fff48ed3280, mode1=PAGE_CUR_GE, tuple2=0x7fff48ed32e0, mode2=PAGE_CUR_G)
  18.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/btr/btr0cur.cc:6044
  19. #8 0x00000000019b3e0e in ha_innobase::records_in_range (this=0x7fff48e7e3b0, keynr=1, min_key=0x7fff57a71680, max_key=0x7fff57a716a0)
  20.     at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:13938
  21. #9 0x0000000000f6ed5b in handler::multi_range_read_info_const (this=0x7fff48e7e3b0, keyno=1, seq=0x7fff57a71b90, seq_init_param=0x7fff57a71850, n_ranges_arg=0,
  22.     bufsz=0x7fff57a71780, flags=0x7fff57a71784, cost=0x7fff57a71d10) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:6440
  23. #10 0x0000000000f70662 in DsMrr_impl::dsmrr_info_const (this=0x7fff48e7e820, keyno=1, seq=0x7fff57a71b90, seq_init_param=0x7fff57a71850, n_ranges=0,
  24.     bufsz=0x7fff57a71d70, flags=0x7fff57a71d74, cost=0x7fff57a71d10) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/handler.cc:7112
  25. #11 0x00000000019be22f in ha_innobase::multi_range_read_info_const (this=0x7fff48e7e3b0, keyno=1, seq=0x7fff57a71b90, seq_init_param=0x7fff57a71850, n_ranges=0,
  26.     bufsz=0x7fff57a71d70, flags=0x7fff57a71d74, cost=0x7fff57a71d10) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/innobase/handler/ha_innodb.cc:21351
  27. #12 0x000000000178c9e4 in check_quick_select (param=0x7fff57a71e30, idx=0, index_only=false, tree=0x7fff48e700e0, update_tbl_stats=true, mrr_flags=0x7fff57a71d74,
  28.     bufsize=0x7fff57a71d70, cost=0x7fff57a71d10) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/opt_range.cc:10030
  29. #13 0x0000000001783305 in get_key_scans_params (param=0x7fff57a71e30, tree=0x7fff48e70058, index_read_must_be_used=false, update_tbl_stats=true,
  30.     cost_est=0x7fff57a74190) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/opt_range.cc:5812
  31. #14 0x000000000177ce43 in test_quick_select (thd=0x7fff4801f4d0, keys_to_use=..., prev_tables=0, limit=18446744073709551615, force_quick_range=false,
  32.     interesting_order=st_order::ORDER_NOT_RELEVANT, tab=0x7fff48eacf20, cond=0x7fff48eacd50, needed_reg=0x7fff48eacf60, quick=0x7fff57a744c8)
  33.     at /root/mysql5.7.14/percona-server-5.7.14-7/sql/opt_range.cc:3066
  34. #15 0x000000000158b9bc in get_quick_record_count (thd=0x7fff4801f4d0, tab=0x7fff48eacf20, limit=18446744073709551615)
  35.     at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:5942
  36. #16 0x000000000158b073 in JOIN::estimate_rowcount (this=0x7fff48eac980) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:5689
  37. #17 0x00000000015893b5 in JOIN::make_join_plan (this=0x7fff48eac980) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:5046
  38. #18 0x000000000157d9b7 in JOIN::optimize (this=0x7fff48eac980) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_optimizer.cc:387
  39. #19 0x00000000015fab71 in st_select_lex::optimize (this=0x7fff48aa45c0, thd=0x7fff4801f4d0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_select.cc:1009
  40. #20 0x00000000015f9284 in handle_query (thd=0x7fff4801f4d0, lex=0x7fff48021ab0, result=0x7fff48aa5dc8, added_options=0, removed_options=0)
  41.     at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_select.cc:164
  42. #21 0x00000000015ac159 in execute_sqlcom_select (thd=0x7fff4801f4d0, all_tables=0x7fff48aa54b8) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5391
  43. #22 0x00000000015a4774 in mysql_execute_command (thd=0x7fff4801f4d0, first_level=true) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:2889
  44. #23 0x00000000015ad12a in mysql_parse (thd=0x7fff4801f4d0, parser_state=0x7fff57a76600) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:5836
  45. #24 0x00000000015a0fe9 in dispatch_command (thd=0x7fff4801f4d0, com_data=0x7fff57a76d70, command=COM_QUERY)
  46.     at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:1447
  47. #25 0x000000000159fe1a in do_command (thd=0x7fff4801f4d0) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/sql_parse.cc:1010
  48. #26 0x00000000016e1d6c in handle_connection (arg=0x6320740) at /root/mysql5.7.14/percona-server-5.7.14-7/sql/conn_handler/connection_handler_per_thread.cc:312
  49. ---Type <return> to continue, or q <return> to quit---
  50. #27 0x0000000001d723f4 in pfs_spawn_thread (arg=0x6320530) at /root/mysql5.7.14/percona-server-5.7.14-7/storage/perfschema/pfs.cc:2188
  51. #28 0x0000003ca62079d1 in start_thread () from /lib64/libpthread.so.0
  52. #29 0x0000003ca5ee8b6d in clone () from /lib64/libc.so.6

作者微信:

img_4166a896a28155d27307bf8bdad181d5.jpg
文章标签：
云数据库 RDS MySQL 版
SQL
关系型数据库
索引
MySQL
存储
关键词：
云数据库 RDS MySQL 版innodb
mysql innodb
云数据库 RDS MySQL 版区别
innodb主键
mysql innodb区别
相关实践学习
如何在云端创建MySQL数据库
开始实验后，系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
重庆八怪
目录
相关文章
WangBai
|
26天前
|
存储 算法 关系型数据库
InnoDB与MyISAM实现索引方式的区别
InnoDB和MyISAM均采用B+树索引，但在实现上有所不同。InnoDB的主键索引在叶子节点存储完整数据记录，辅助索引则存储主键值；而MyISAM的主键索引与数据文件分离，仅存数据地址，且主辅索引无区别，支持非唯一主索引。
WangBai
41 1
WangBai
|
16天前
|
存储 关系型数据库 MySQL
MySQL引擎InnoDB和MyISAM的区别？
InnoDB是MySQL默认的事务型存储引擎，支持事务、行级锁、MVCC、在线热备份等特性，主索引为聚簇索引，适用于高并发、高可靠性的场景。MyISAM设计简单，支持压缩表、空间索引，但不支持事务和行级锁，适合读多写少、不要求事务的场景。
WangBai
48 9
爱吃香蕉的猫
|
24天前
|
安全 关系型数据库 数据库
MyISAM和InnoDB的区别
InnoDB支持事务，MyISAM不支持 InnoDB支持外键，MyISAM不支持 InnoDB是聚簇索引，MyISAM是非聚簇索引 InnoDB支持行锁和表锁，MyISAM只支持表锁；【并发情况下，InnoDB性能更牛，默认一锁只会锁住一行数据】 InnoDB不支持全文索引，MyISAM支持 InnoDB支持自增和MVCC模式的读写，MyISAM不支持 InnoDB支持支出数据库异常崩溃后的安全恢复，MyISAM不支持【崩溃后，重启会保证数据恢复到崩溃前状态。这个恢复的过程依赖于redo.log】
爱吃香蕉的猫
23 4
最好zzz
|
1月前
|
存储 关系型数据库 MySQL
MySQL 字段类型探究：深入理解 Varchar(50) 与 Varchar(500)
在MySQL数据库中，`VARCHAR`类型是一种常用的字符串存储类型，它允许定义一个可变长度的字符串。然而，`VARCHAR(50)`和`VARCHAR(500)`之间的差异不仅仅是长度的不同，它们在存储和性能方面也有显著的区别。本文将深入探讨这两种字段类型的区别，以及它们在实际应用中的选择。
最好zzz
104 3
潇洒洒
|
1月前
|
存储 关系型数据库 MySQL
MySQL 字段类型深度解析：VARCHAR(50) 与 VARCHAR(500) 的差异
在MySQL数据库中，`VARCHAR`类型是一种非常灵活的字符串存储类型，它允许存储可变长度的字符串。然而，`VARCHAR(50)`和`VARCHAR(500)`之间的差异不仅仅是长度的不同，它们在存储效率、性能和使用场景上也有所不同。本文将深入探讨这两种字段类型的区别及其对数据库设计的影响。
潇洒洒
54 2
热爱技术的小郑
|
4月前
|
存储 关系型数据库 MySQL
一天五道Java面试题----第八天（怎么处理慢查询---------＞简述Myisam和innodb的区别）
这篇文章是关于Java面试中关于数据库性能优化和MySQL特性的五个问题，包括处理慢查询、ACID特性保证、MVCC概念、MySQL主从同步原理以及MyISAM和InnoDB存储引擎的区别。
热爱技术的小郑
36 1
菜菜的后端私房菜
|
7月前
|
存储 关系型数据库 MySQL
MySQL字段的字符类型该如何选择?千万数据下varchar和char性能竟然相差30%🚀
本篇文章来讨论MySQL字段的字符类型选择并深入实践char与varchar类型的区别以及在千万数据下的性能测试
菜菜的后端私房菜
519 14
MySQL字段的字符类型该如何选择?千万数据下varchar和char性能竟然相差30%🚀
qiuqiushuibx
|
7月前
|
SQL 关系型数据库 MySQL
unsigned int 虽然mysql支持,但是不建议使用,因为可能在未来某个版本删除
unsigned int 虽然mysql支持,但是不建议使用,因为可能在未来某个版本删除
qiuqiushuibx
51 2
冷色系456
|
7月前
|
存储 SQL 关系型数据库
mysql中MyISAM和InnoDB的区别是什么
mysql中MyISAM和InnoDB的区别是什么
冷色系456
56 0
AIweker
|
11天前
|
关系型数据库 MySQL 数据库
Python处理数据库：MySQL与SQLite详解 | python小知识
本文详细介绍了如何使用Python操作MySQL和SQLite数据库，包括安装必要的库、连接数据库、执行增删改查等基本操作，适合初学者快速上手。
AIweker
80 15

热门文章

最新文章

  • 1
    .replace(R.id.container, new User()).commit();/The method replace(int, Fragment) in the type FragmentTransaction is not app
  • 2
    java int与integer的区别
  • 3
    C#，int转成string，string转成int
  • 4
    函数Int3断点检测
  • 5
    <转>零值比较--BOOL，int，float，指针变量与零值比较的if语句
  • 6
    C++ int与string的转化
  • 7
    C++输出 int 型的二进制表示
  • 8
    Convert、Parse、TryParse、(int) 的区别
  • 9
    RxJava/RxAndroid:ConnectableObservable &amp; replay(int bufferSize)
  • 10
    基于X86平台的PC机通过网络发送一个int（32位）整数的字节顺序
  • 1
    10个行锁、死锁案例⭐️24张加锁分析图🚀彻底搞懂Innodb行锁加锁规则！
    373
  • 2
    MySQL高可用解决方案演进：从主从复制到InnoDB Cluster架构
    334
  • 3
    mysql中MyISAM和InnoDB的区别是什么
    56
  • 4
    【MySQL系列笔记】InnoDB引擎-数据存储结构
    441
  • 5
    【MySQL】InnoDB 什么情况下会产生死锁
    218
  • 6
    详解InnoDB(2)——日志
    125
  • 7
    详解InnoDB(1)——事务
    89
  • 8
    InnoDB中的索引方案
    65
  • 9
    MySQL InnoDB引擎（下）
    57
  • 10
    MySQL InnoDB引擎（上）
    62

    • 相关课程

    更多
  • MySQL企业常见架构与调优经验分享
  • 云数据库MySQL版快速上手教程
  • 阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
  • MySQL实战进阶
  • 数据库及SQL/MySQL基础
  • 云数据库MySQL快速入门

    • 相关电子书

    更多
  • One Box： 解读事务与分析一体化数据库 HybridDB for MySQL
  • One Box：解读事务与分析一体化数据库HybridDB for MySQL
  • 如何支撑HTAP场景-HybridDB for MySQL系统架构和技术演进

    • 相关实验场景

    更多
  • MySQL引擎及架构优化
  • 基于EBS部署高性能的MySQL服务
  • 5分钟上手Flink MySQL连接器
  • 云端MySQL的安装及应用
  • 手动部署MySQL数据库（Alibaba Cloud Linux 2）
  • 手动部署MySQL数据库（CentOS 7）

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    DataWorks