切记切记： 关联关系的话，比如user表（用户）id name把id设为主键与文章表article id name user_id把user_id设为索引外键，关联关系的话，是用户表的id与文章表的user_id 因为用户表的id是主表的主键id。从表的user_id是外键啊.而关联关系是主表的主键id与从表的外键id相关联的啊 主从表，从表数据依赖于主表，一般最后查询数据时把主表与从表进行关联查询。 主表可用于存储主要信息，如客户资料（客户编号，客户名称，客户公司，客户单位等），从表用来存储客户扩展信息（客户订单信息，客户地址信息，客户联系方式信息等）。 主表： 在数据库中建立的表格即Table，其中存在主键(primary key)用于与其它表相关联，并且作为在主表中的唯一性标识。 从表： 以主表的主键（primary key）值为外键 (Foreign Key)的表，可以通过外键与主表进行关联查询。从表与主表通过外键进行关联查询。 关系及用法概述
创建架构，复合主键,主表，从表的创建方法。 null, u_id int constraint PK_ID primary key(id,s_id,u_id)--创建复合主键 ) create table XIXI.O(--主表 id int constraint PK_OK primary key, ) create table XIXI.K(--从表 id int constraint FK_id foreign key(id) references XIXI.O(id) ) --先删从表再删主表 drop table XIXI.K drop table XIXI.O create type Happy_HAHA
热卖云产品新年特惠，2核2G轻量应用服务器9元/月起，更多上云必备产品助力您轻松上云
学习Excel技术，关注微信公众号： excelperfect 这是在ozgrid.com的论坛中看到的一个应用问题，以前也经常遇到类似问题，并且其解决技巧很有效率，因此在这里和大家分享。 如下图1所示的工作表，在主工作表MASTER中存放着从数据库下载的全部数据。 ，同样，开头数字是63的复制到工作表63中，开头数字是64或65的复制到工作表64_65中，开头数字是68的复制到工作表68中。 CurrentRegion '清除原有内容，标题行除外 .Offset(1).Resize(.Rows.Count,12).ClearContents '从单元格 将数组数据直接输入到工作表单元格，提高了代码的简洁性和效率。 将代码适当修改，可以方便地实现类似的需求。 代码的图片版如下： ?
由于数据库设计时，将tag标签独立，并没有作为article文章表的一个字段。通过一个中间关联表（art_tag）来对应文章表（article）和tag表（tags）之间的映射关系。 通过查询tags表中的数据，以art_tag表中的映射数量进行排序操作。 先来看下三个表结构涉及的字段。 1、文章表（article）：文章ID（id） 2、标签表（tags）：标签ID（id）、标签名（tag_name） 3、中间表（art_tag）：序号（id）、文章ID（article_id）、标签ID 业务目标即：对art_tag表中的tags_id进行count计数作为tags表查询的排序依据。 这其中牵扯到两次查询，首先查询tags表，第二是需要对art_tag表中对应的tags_id做count查询。
上一篇是正常思维，通过查询tag表中的id在关联表中做count查询查询，最后以count依据截取需要的部分内容返回给控制器。 首先通过查询中间表中的tags_id列，将查询结果通过array_count_values函数做一个计数操作（关键就在这里，通过使用数组来计数达到避开循环中使用count查询）。 后续对这个数组截取需要的部分在tag表中使用in查询，返回最终查询结果即可。 和前面的数据进行对比可见，耗时节约70%，内存消耗减少50%以上。性能提升还是非常明显的。性能提升的关键在用PHP数组内置函数去代替了count计数查询，第二是截取需要的部分进行最后的数据查询。
邻接表作为图的一种存储方式，在存储稀疏图上相对于邻接矩阵有相当大的空间节省。如一个稀疏图的顶点个个数为n，边数为e。 但是对于邻接表来讲，存储空间只需要n+2e个，相对于邻接矩阵减少了很多。邻接表虽然在空间上有很大的优势，但是对于一个有向图，如果需要查找每个顶点的入度就需要遍历整个邻接表，在效率上很低下的。 因此才有了逆邻接表的诞生。 邻接表：反映的是顶点出度的情况。 逆邻接表：反映的是顶点的入度情况。 下面举一个例子： 邻接表： 逆邻接表：
临时表适用数据量较大的情况，因为临时表可以建立索引 2. 表变量适用于数据较小的情况，表变量只能在定义时创建约束(PRIMARY KEY/UNIQUE)从而间接建立索引 3. 临时表是事务性的，数据会随着事务回滚而回滚，表变量是非事务性的 4. 临时表和表变量都存放在内存中，当内存存在压力时才放入到硬盘 5. 临时表的创建删除会导致存储过程重编译,而在存储过程中使用表变量不会引发重编译 8. 用户定义的临时对象(临时表、全局临时表、表变量、游标)都优先存放到内存 9. 临时表和表变量在数据操作时产生的日志远远低于普通表 10.除非使用 DROP TABLE 显式删除临时表，否则临时表将在退出其作用域时由系统自动删除： 1)当存储过程完成时，将自动删除在存储过程中创建的本地临时表 由创建表的存储过程执行的所有嵌套存储过程都可以引用此表。但调用创建此表的存储过程的进程无法引用此表。 2)所有其他本地临时表在当前会话结束时都将被自动删除。
清空表和截断表 清空表：delete from users； 清空表只是清空表中的逻辑数据，但是物理数据不清除，如主键值、索引等不被清除，还是原来的值。 截断表：truncate table users； 截断表可以用于删除表中 的所有数据。截断表命令还会回收所有索引的分配页。 截断表的执行速度与不带where子句的delete（删除）命令相同，甚至比它还要快。 delete（删除）一次删除一行数据，并且将每一行被删除的数据都作为一个事务记录日志；而truncate （截断）表则回收整个数据页，只记录很少的日志项。 delete（删除）和truncate（截断）都会回收被数据占用的空间，以及相关的索引。只有表的 拥有者可以截断表。 另外，truncate表之后，如果有自动主键的话，会恢复成默认值。
临时表特点： 建表语法是create temporary table 一个临时表只能被创建它的session访问，对其他线程不可见。 临时表和普通表可以同名。 同一个session内有临时表和普通表的时候，show crete语句、增删改查访问的是临时表。 show tabls命令不显示临时表。 我们举例的这条语句还算是比较简单的，如果涉及到复杂的操作，比如 group by，甚至 join 这样的操作，对中间层的开发能力要求比较高； 对 proxy 端的压力比较大，尤其是很容易出现内存不够用和 以及之前的版本里，MySQL 会在临时文件目录下创建一个相同前缀、以.ibd 为后缀的文件，用来存放数据文件； 而从 5.7 版本开始，MySQL 引入了一个临时文件表空间，专门用来存放临时文件的数据 临时表和主备复制 临时表的操作也会记录到binlog，既然写binlog，意味着备库也会执行。
Hive 内部表和外部表 示例 CREATE TABLE page_view( viewTime INT, userid BIGINT, page_url STRING, ,有表的注释，一个字段ip的注释，分区有两列,分别是dt和country。 有指定EXTERNAL就是外部表，没有指定就是内部表，内部表在drop的时候会从HDFS上删除数据，而外部表不会删除。 外部表和内部表一样，都可以有分区，如果指定了分区，那外部表建了之后，还要修改表添加分区。 外部表如果有分区，还可以加载数据，覆盖分区数据，但是外部表删除分区，对应分区的数据不会从HDFS上删除，而内部表会删除分区数据。
点击跳转到网站：https://www.captainai.net/dongkelun前言总结一下Hive的内部表和外部表以及两者的区别。 FIELDS TERMINATED BY ',' ;仅从建表语句上看，内部表和外部表的区别为是否带有external关键字。 如果不加location那么不管是内部表还是外部表都会在默认的hive配置的hdfs路径下下新建一个和表名相同的文件夹。 3、删除表内部表和外部表的区别主要体现在删除表，将上面建立的四个表都删掉。 文件夹和external_location文件夹都存在，而内部表的两个文件夹都没了，这也就是内部表和外部表的区别： 内部表删除表时，对应的hdfs的路径下的文件会删掉；外部表删除表时，对应的HDFS的路径下的文件则不会删掉
需求描述 某电商数据库中存在一张客户信息表user_info，记录着客户属性数据和消费数据，需要将左边长格式数据转化成右边宽格式数据。 ? 需求实现 做以下说明 ?
、 一、非事务表 Nontransactional Tables，非事务表，不支持事务的表，也就是使用MyISAM存储引擎的表。 ，显示非事务表不支持回滚。 二、事务表 与非事务表对象的是事务表，比如使用InnoDB的表，支持回滚操作。 三、相关参数 max_binlog_stmt_cache_size 该参数影响的是非事务表，如MyISAM，该参数不够时，则提示需要更多的空间。 max_binlog_cache_size 该参数影响的是事务表，如InnoDB，该参数不够时，则提示需要更多的空间。
大家好，又见面了，我是你们的朋友全栈君。 select m.* from t_menu m where m.stat...
快乐，是精神和肉体的朝气，是希望和信念，是对自己的现在和来来的信心，是一切都该如此进行的信心。 ——果戈理 今天做了个小测试啊 我自己造了一百万多条(1029708条)数据 这里测试呢我们首先是编写了一个LEFT JOIN 连表SQL如下 SELECT * FROM `film` ` ON `film`.language_id = `language`.language_id 我们查询一百万多条后耗时为33457.8317 ms，大约30来秒，这是没有加索引的情况下 我们使用单表查询 发现仅仅多了一秒左右啊 上面的连表SQL，就算在language表的language_id上加了索引，也是耗时35314.184 ms 也远远没有我们的单表快 所以结论： 同样的数据，单表多次查询在正确使用下 ，比连表确实快不少 但连表只需要一条SQL而单表需要写一大堆代码
php artisan make:migration create_table_test –table=test_a 修改表 Schema::table(‘test’, function (Blueprint string’,’t_id’, [‘length’ => 200]); }); php artisan make:migration create_table_test –create=test_a 创建表
因为云平台的备份是把库中所有的表都打包成一个 .sql文件，然而这一个.sql文件大约有20G，现阶段的方法是把.sql文件source到数据库数据处理机器上，然后再根据需求提出需要的表。 思路(原谅我也理解了好一会儿)： 主要使用sed命令来实现，加上-n,-e参数把打印的结果追加到一个文件中，就得到了想要的表的内容。 我们使用如下sed命令从原始sql中导出wp_comments表： 意思是:打印DROP TABLE. 此时，lianst.wp_comments.sql 就是我们从原始备份sql（lianst.sql）中导出的wp_comments表的sql语句。接下来我们就可以针对这一个表来进行恢复了。
分布式数据库 TDSQL MySQL版是腾讯打造的一款分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性，同时提供智能 DBA、自动化运营、监控告警等配套设施，为客户提供完整的分布式数据库解决方案。目前 TDSQL 已经为超过500+的政企和金融机构提供数据库的公有云及私有云服务，客户覆盖银行、保险、证券、互联网金融、计费、第三方支付、物联网、互联网+、政务等领域。TDSQL MySQL 版亦凭借其高质量的产品及服务，获得了多项国际和国家认证，得到了客户及行业的一致认可。
扫码关注腾讯云开发者
领取腾讯云代金券
云服务器
云数据库 SQL Server
网站备案
文件存储
SSL 证书
