• 关于 数据库排序语句 的搜索结果

回答

1、LIMIT 语句 分页查询是最常用的场景之一,但也通常也是最容易出问题的地方。比如对于下面简单的语句,一般 DBA 想到的办法是在 type, name, create_time 字段上加组合索引。这样条件排序都能有效的利用到索引,性能迅速提升。 好吧,可能90%以上的 DBA 解决该问题就到此为止。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时,程序员仍然会抱怨:我只取10条记录为什么还是慢?要知道数据库也并不知道第1000000条记录从什么地方开始,即使有索引也需要从头计算一次。出现这种性能问题,多数情形下是程序员偷懒了。在前端数据浏览翻页,或者大数据分批导出等场景下,是可以将上一页的最大值当成参数作为查询条件的。SQL 重新设计如下: 在新设计下查询时间基本固定,不会随着数据量的增长而发生变化。 2、隐式转换 SQL语句中查询变量和字段定义类型不匹配是另一个常见的错误。比如下面的语句: 其中字段 bpn 的定义为 varchar(20),MySQL 的策略是将字符串转换为数字之后再比较。函数作用于表字段,索引失效。上述情况可能是应用程序框架自动填入的参数,而不是程序员的原意。现在应用框架很多很繁杂,使用方便的同时也小心它可能给自己挖坑。 3、关联更新、删除 虽然 MySQL5.6 引入了物化特性,但需要特别注意它目前仅仅针对查询语句的优化。对于更新或删除需要手工重写成 JOIN。比如下面 UPDATE 语句,MySQL 实际执行的是循环/嵌套子查询(DEPENDENT SUBQUERY),其执行时间可想而知。 执行计划: 重写为 JOIN 之后,子查询的选择模式从 DEPENDENT SUBQUERY 变成 DERIVED,执行速度大大加快,从7秒降低到2毫秒 执行计划简化为: 4、混合排序 MySQL 不能利用索引进行混合排序。但在某些场景,还是有机会使用特殊方法提升性能的。 执行计划显示为全表扫描: 由于 is_reply 只有0和1两种状态,我们按照下面的方法重写后,执行时间从1.58秒降低到2毫秒。 5、EXISTS语句 MySQL 对待 EXISTS 子句时,仍然采用嵌套子查询的执行方式。如下面的 SQL 语句: 执行计划为: 去掉 exists 更改为 join,能够避免嵌套子查询,将执行时间从1.93秒降低为1毫秒。 新的执行计划: 6、条件下推外部查询条件不能够下推到复杂的视图或子查询的情况有: 聚合子查询; 含有 LIMIT 的子查询; UNION 或 UNION ALL 子查询; 输出字段中的子查询; 如下面的语句,从执行计划可以看出其条件作用于聚合子查询之后 确定从语义上查询条件可以直接下推后,重写如下: 执行计划变为: 7、提前缩小范围 先上初始 SQL 语句: 数为90万,时间消耗为12秒。 由于最后 WHERE 条件以及排序均针对最左主表,因此可以先对 my_order 排序提前缩小数据量再做左连接。SQL 重写后如下,执行时间缩小为1毫秒左右。 再检查执行计划:子查询物化后(select_type=DERIVED)参与 JOIN。虽然估算行扫描仍然为90万,但是利用了索引以及 LIMIT 子句后,实际执行时间变得很小。 8、中间结果集下推 再来看下面这个已经初步优化过的例子(左连接中的主表优先作用查询条件): 那么该语句还存在其它问题吗?不难看出子查询 c 是全表聚合查询,在表数量特别大的情况下会导致整个语句的性能下降。其实对于子查询 c,左连接最后结果集只关心能和主表 resourceid 能匹配的数据。因此我们可以重写语句如下,执行时间从原来的2秒下降到2毫秒。 但是子查询 a 在我们的SQL语句中出现了多次。这种写法不仅存在额外的开销,还使得整个语句显的繁杂。使用 WITH 语句再次重写: 总结数据库编译器产生执行计划,决定着SQL的实际执行方式。但是编译器只是尽力服务,所有数据库的编译器都不是尽善尽美的。上述提到的多数场景,在其它数据库中也存在性能问题。了解数据库编译器的特性,才能避规其短处,写出高性能的SQL语句。程序员在设计数据模型以及编写SQL语句时,要把算法的思想或意识带进来。编写复杂SQL语句要养成使用 WITH 语句的习惯。简洁且思路清晰的SQL语句也能减小数据库的负担 。

茶什i 2020-01-13 11:11:06 0 浏览量 回答数 0

回答

高可用: 采用主从热备的架构。主机down机或者出现故障后,备机秒级完成无缝切换,服务可用性承诺:99.95% 提供自动多重备份的机制。用户可以自行选择备份周期,也可以根据自身业务特点随时进行临时备份,数据可靠性承诺:99.9999% 数据回溯到任意时间点。用户可以选择7天内的任意时间点创建一个临时实例,临时实例生成后验证数据无误,即可将数据迁移到RDS实例,从而完成数据回溯操作。 ★高安全 提供白名单访问策略。可自行设置允许访问的IP及IP段,有效防止黑客扫描端口进行服务器攻击。 提供阈值报警的功能。支持实例锁定报警、连接数报警、IOPS报警、磁盘空间使用报警、CPU报警等。 提供SQL注入告警。将对发往RDS的疑似SQL注入的语句进行记录并展示,供用户进行程序调整,杜绝SQL注入的发生。 SQL审计。记录所有发往RDS的SQL语句,系统将记录SQL语句相关的连接IP、访问数据库的名称、执行语句的账号、执行时间、返回记录数等信息。供用户对RDS安全性进行排查。 控制台操作日志。记录所有在控制台上进行的修改类操作,便于管理员查看并管理RDS。 ★高性能 RDS使用高端服务器来保障每个数据库都拥有良好的性能。 针对MySQL类型的RDS,数据库版本融合了阿里巴巴官方数据库补丁,有效的提升了RDS的性能。 性能监控。提供多种监控图方便用户跟踪RDS的性能状况。如IOPS、连接数、磁盘使用空间、CPU利用率、QPS\TPS、网络流量以及多种数据库的内部监控指标图 慢SQL汇总分析。将数据库中的慢SQL进行相似语句去重,按照指定方式排序后进行展示,为用户排查慢SQL优化数据库性能提供帮助。 优化建议。提供多种优化建议方便用户优化数据库性能,如:存储引擎检查、大表检查、无主键检查、索引过多表检查、缺失索引检查等 ★易用性: 提供向导式迁移服务,使用户能够通过WEB端管理控制台轻松将自建数据库迁移至RDS。 快捷查看数据库系统日志,用户能够RDS管理控制台查看数据库级别的系统日志。 便捷操作数据库实例。提供完善的WEB端管理控制台,帮助用户操作数据库实例,如重启实例、删除BINLOG、备份等等。 轻松升级,按量付费。RDS提供实例配置和数据库版本的在线升级服务,随开随用,按量付费,资源业务轻松拓展。 答案来源于网络

养狐狸的猫 2019-12-02 02:17:57 0 浏览量 回答数 0

回答

mysql根据多个字段查找 在mysql中,如果要实现根据某个字段排序的时候,可以使用下面的SQL语句 SELECT * FROM 'TABLE_NAME' ORDER BY 'Field' 然而,如果要实现根据某个字段排序后再根据另一个字段排序的时候应该如何呢?可以使用下面的SQL语句 SELECT * FROM 'TABLE_NAME' ORDER BY FIELD1, FIELD2; 如果要加上排序的话 SELECT * FROM 'TABLE_NAME; ORDER BY FIELD1 DESC, FIELD2; 置顶功能的实现 下面给一个对两个字段实现排序的例子 在一个项目中需要实现这样的功能,我的做法是在数据库里面增加一个字段,该字段标识帖子的权重,权重高的就往前排,如果权重相等的就根据时间排序,这样就实现了置顶的功能。 SELECT * FROM 'TABLE_NAME' ORDER BY PIORITY DESC, DATA DESC;

落地花开啦 2019-12-02 01:48:53 0 浏览量 回答数 0

新用户福利专场,云服务器ECS低至102元/年

新用户专场,1核2G 102元/年起,2核4G 699.8元/年起

回答

RDS是阿里云提供的即开即用的关系型数据库服务,兼容了MySQL和SQL Server两种数据库引擎。在传统数据库的基础上,阿里云RDS提供了强大丰富的功能从而保证了高可用性、高安全性以及高性能。此外,RDS还提供了诸多便利功能提升了RDS的易用性。 ★高可用: 采用主从热备的架构。主机down机或者出现故障后,备机秒级完成无缝切换,服务可用性承诺:99.95% 提供自动多重备份的机制。用户可以自行选择备份周期,也可以根据自身业务特点随时进行临时备份,数据可靠性承诺:99.9999% 数据回溯到任意时间点。用户可以选择7天内的任意时间点创建一个临时实例,临时实例生成后验证数据无误,即可将数据迁移到RDS实例,从而完成数据回溯操作。 ★高安全 提供白名单访问策略。可自行设置允许访问的IP及IP段,有效防止黑客扫描端口进行服务器攻击。 提供阈值报警的功能。支持实例锁定报警、连接数报警、IOPS报警、磁盘空间使用报警、CPU报警等。 提供SQL注入告警。将对发往RDS的疑似SQL注入的语句进行记录并展示,供用户进行程序调整,杜绝SQL注入的发生。 SQL审计。记录所有发往RDS的SQL语句,系统将记录SQL语句相关的连接IP、访问数据库的名称、执行语句的账号、执行时间、返回记录数等信息。供用户对RDS安全性进行排查。 控制台操作日志。记录所有在控制台上进行的修改类操作,便于管理员查看并管理RDS。 ★高性能 RDS使用高端服务器来保障每个数据库都拥有良好的性能。 针对MySQL类型的RDS,数据库版本融合了阿里巴巴官方数据库补丁,有效的提升了RDS的性能。 性能监控。提供多种监控图方便用户跟踪RDS的性能状况。如IOPS、连接数、磁盘使用空间、CPU利用率、QPS\TPS、网络流量以及多种数据库的内部监控指标图 慢SQL汇总分析。将数据库中的慢SQL进行相似语句去重,按照指定方式排序后进行展示,为用户排查慢SQL优化数据库性能提供帮助。 优化建议。提供多种优化建议方便用户优化数据库性能,如:存储引擎检查、大表检查、无主键检查、索引过多表检查、缺失索引检查等 ★易用性: 提供向导式迁移服务,使用户能够通过WEB端管理控制台轻松将自建数据库迁移至RDS。 快捷查看数据库系统日志,用户能够RDS管理控制台查看数据库级别的系统日志。 便捷操作数据库实例。提供完善的WEB端管理控制台,帮助用户操作数据库实例,如重启实例、删除BINLOG、备份等等。 轻松升级,按量付费。RDS提供实例配置和数据库版本的在线升级服务,随开随用,按量付费,资源业务轻松拓展。 “答案来源于网络,供您参考” 希望以上信息可以帮到您!

牧明 2019-12-02 02:16:59 0 浏览量 回答数 0

回答

优化大致可以分为以下方面,按照执行难易程度和对当前项目影响排序:MySQL参数优化:可以通过show variables;命令和show status;命令组合来综合分析,可调整的项目根据使用的存储引擎和项目瓶颈具体情况千差万别,需要具体问题具体分析,如果想从这方面入手,建议把问题提得更具体一点;SQL查询优化和索引优化:你可以打开慢日志记录,将需要消耗太多时间的查询记录下来,然后分析相应的SQL语句是否写的不合理,不合理就改了;再到数据库中查表结构,看是否索引设置不合理(一般where语句中的常用字段和排序字段应该加上合适的索引);增加缓存层:可考虑在MySQL与应用层中间加一个缓存层,如APC、Memcached、Redis等等,将经常使用而更新较少的数据放到缓存层中,可以很好的减轻数据库压力;优化表结构:首先这个代价稍大,可能要重新灌数据之类的,代码修改可能也会比较多,看之前的封装性好不好了。主要是根据业务需要,看是否之前的表结构有不合理的地方,比如你使用了很多但是又无法排除的join查询;分库、分表、主从分离:分库是把数据库从1个逻辑库拆分到多个逻辑库,或从1个服务器拆分到多个服务器,分表是将一个表拆分为多个表,甚至是多个物理服务器的不同表;主从分离是将读、写完全分离到不同的数据库服务器;这个方案跟4一样,也是代价比较大,但是可持续性很好,项目到达一定的数量级,必须走这一步;自己定制MySQL:开源的,可以根据自己特殊业务需要定制,太高端了点点,总之有这种可能,没搞过...

西秦说云 2019-12-02 01:33:16 0 浏览量 回答数 0

回答

MySQL 5.6 主要在查询性能的优化、InnoDB改进以支持高吞吐量的事务、NoSQL风格的API、分区功能的改进、数据复制的改进,增加 PERFORMANCE_SCHEMA 库以获得数据库性能信息等。1. 查询性能优化:下推索引条件:具体实现方法不详,意思是将优化 WHERE 语句改进索引条件的处理性能Multi-Range Read:通过随机数据访问来提升 SSD 上的数据读取速度优化文件排序:对一些组合了ORDER BY non_indexed_column 和 LIMIT x 的SQL语句,该特性将大大加速此类语句的执行速度。2. InnoDB 的改进MySQL 5.6 完全集成 InnoDB 作为默认的存储引擎。同时 5.6 版本在使用 InnoDB 上的很多细节做了改进,详情请看这里。3. 提供 NoSQL 风格的 API此举完全是寨 Percona Server 的做法?该功能主要适用于将 MySQL 来作为 NoSQL 使用,而 MySQL 使用的是 memcached 兼容的 API。通过该接口程序访问数据可直达 InnoDB 存储引擎,而无需通过 MySQL 对 SQL 的转换过程,大大提升了数据访问的性能。4. 分区的改进显式分区数据查询,例如:`SELECT * FROM employees PARTITION (p0, p2);DELETE FROM employees PARTITION (p0, p1);UPDATE employees PARTITION (p0) SET store_id = 2 WHERE fname = 'Jill';SELECT e.id, s.city FROM employees AS e JOIN stores PARTITION (p1) AS s ...;`分区数据的导入导出,此功能用于快速的将某个表迁移到分区上:ALTER TABLE e EXCHANGE PARTITION p0 WITH TABLE e2;5. 复制功能的改进优化基于行的数据复制、多线程的数据复制、提升数据复制的一致性和可用性。6. 大大增强 PERFORMANCE_SCHEMA 数据库降低了数据库开销、表IO的信息汇集和监控、表锁信息汇集和监控、会话和用户级别的监控、全局性能信息汇总

落地花开啦 2019-12-02 01:42:25 0 浏览量 回答数 0

问题

Eclipse用户指南:使用阿里云图形界面:RDS图形化界面

行者武松 2019-12-01 21:51:20 1802 浏览量 回答数 0

回答

使用 sql 语句修改数据库字符集的方法: 语法如下:  修改库: ALTER DATABASE 库名 CHARACTER SET 字符集名称 COLLATE 排序规则名称; 修改表: ALTER TABLE 表名 CONVERT TO CHARACTER SET 字符集名称 COLLATE 排序规则名称; 修改一列: ALTER TABLE 表名 MODIFY 列名 字段类型 CHARACTER SET 字符集名称 COLLATE 排序规则名称; 示例: 下面三条sql 分别将库 dbsdq , 表 tt2 , 表 tt2 中的 c2 列修改为utf8mb4 字符集, 代码如下:  alter database dbsdq character set utf8mb4 collate utf8mb4_unicode_ci; use dbsdq; alter table tt2 character set utf8mb4 collate utf8mb4_unicode_ci; alter table tt2 modify c2 varchar(10) character set utf8mb4; 如图:  注意: 修改列时,当前列中的所有行都会立即转化为新的字符集; alter table 会对表加元数据锁(metadata lock), 详见: https://help.aliyun.com/knowledge_detail/6697124.html

qq78315851 2019-12-02 00:05:58 0 浏览量 回答数 0

问题

mysql双字段排序问题

落地花开啦 2019-12-01 19:55:00 1032 浏览量 回答数 1

问题

【RDS系列二】别总等数据库宕了才想起我

belle.zhoux 2019-12-01 21:49:29 17195 浏览量 回答数 15

回答

根据你自己提供的sql语句排序,不同的数据库sql不同,这里以mysql为例select * from 表 order by 字段 [asc|desc] limit 100, 100

a123456678 2019-12-02 03:03:23 0 浏览量 回答数 0

问题

求问数据库的多个表自然连接后得到的结果怎么设置以一个属性排序

茶什i 2019-12-01 19:52:50 9 浏览量 回答数 0

回答

当用户的 SQL 语句需要磁盘空间来完成某个操作时,DM 数据库会从 TEMP 表空间分配临时段。如创建索引、无法在内存中完成的排序操作、SQL 语句中间结果集以及用户创建的临时表等都会使用到 TEMP表空间。 如果你的TEMP表空间很大,那说明你的业务当中存在很多急需优化的SQL。TEMP表空间在重启后会释放掉,也可以手动回收。

茶什i 2019-12-02 03:18:49 0 浏览量 回答数 0

回答

SQL分啊######回复 @蜀山客 : 客气了,共同学习######回复 @CrazyHarry : 谢谢哥!我看明白了。######回复 @蜀山客 : select * from (select 字段1,字段2,字段3,字段4,字段5,rownumber() over(order by 排序字段 asc ) as rowid from 表名 )as a where a.rowid >= startPage AND a.rowid <endPage######这样的sql语句不就可以分页了吗######回复 @CrazyHarry : DB2######明天给你个高大上的sql分页查询语句######hibernate分页好简单######参考一下hibernate的分页查询语句组装代码就可以知道了######没用过db2###### sql分页才是真正的物理数据库层面的分页。你所说的结果及再分页算是逻辑上的分页。 分页主要是为了解决查询结果集太多造成的IO瓶颈,影响数据库查询效率的问题。

kun坤 2020-06-14 10:22:01 0 浏览量 回答数 0

回答

.1. 方案一:(利用Not In和SELECT TOP分页)效率次之 语句形式: SELECT TOP 10 * FROM TestTable WHERE(ID NOT IN (SELECT TOP 20 id FROM TestTable ORDERBY id)) ORDERBYID SELECT TOP 页大小 * FROM TestTable WHERE( ID NOT IN (SELECT TOP 每页大小-1*待查询页数-1 id FROM 表 ORDERBY id)) ORDERBYID 思路:先查询出待查询页之前的全部条数的id,查询ID不在这些ID中的指定数量条数。 方案二:(利用ID大于多少和SELECT TOP分页)效率最高 语句形式: SELECT TOP 10 * FROM TestTable WHERE(ID>(SELECT MAX(id) FROM(SELECT TOP20 id FROM TestTable ORDERBYid)AS T))ORDERBY ID SELECT TOP 页大小* FROM TestTable WHERE(ID>(SELECT MAX(id) FROM(SELECT TOP 每页大小*待查询页数-1 id FROM 表 ORDERBY id)AS T)) ORDERBY ID 思路:先获得待查询页的之前全部条数id,获得它们当中最大的ID号,以此最大ID号为标志,查找比这个ID号大的指定条数。 3.方案三: SELECT TOP PageSize * FROM(SELECT TOP nPage*PageSize * from YOURTABLE order by id)as a order by id desc SELECT TOP 每页条数 * FROM (SELECT TOP 待查询页*每页条数) * from YOURTABLE order by id)as a order by id desc 思路:先正排序查询出待查询页之前(包括当前页)的全部条数,然后将其倒排序,取指定条数。 再补充两种: 4.插入临时表方法: 主要实现为 第一步根据排序建立临时表。 临时表插入排序后选择数据的rowId. 然后用联合的方法来实现排序。用到上面第三种方法。 该方法是通过一个只有主键及排序字段的临时表来进行分页,一般要求要建立存储过程。该方法最致命的问题是,当数据量较大时,要求建立一个根原表同样多条记录的主键,rowid,排序字段临时表,造成效率低下。一般不采用。 5.ROW_NUMBER.来进行分页. ROW_NUMBER 返回结果集分区内行的序列号,每个分区的第一行从 1 开始。 以下示例将返回行号为50到60(含)的行,并以OrderDate排序。 USE AdventureWorks; GO WITH OrderedOrders AS (SELECT SalesOrderID, OrderDate,ROW_NUMBER() OVER (order by OrderDate)as RowNumber FROM Sales.SalesOrderHeader ) SELECT * FROM OrderedOrders WHERE RowNumber between 50 and 60; 该方法,主要是sql server2005以上版本中独有的功能,不适合于sql server2000及Access数据库,对数据库进行分区操作效率也不高。

养狐狸的猫 2019-12-02 02:11:36 0 浏览量 回答数 0

回答

索引,索引!!!为经常查询的字段建索引!! 但也不能过多地建索引。insert和delete等改变表记录的操作会导致索引重排,增加数据库负担。优化目标1.减少 IO 次数 IO永远是数据库最容易瓶颈的地方,这是由数据库的职责所决定的,大部分数据库操作中超过90%的时间都是 IO 操作所占用的,减少 IO 次数是 SQL 优化中需要第一优先考虑,当然,也是收效最明显的优化手段。2.降低 CPU 计算 除了 IO 瓶颈之外,SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户(这些操作基本上都是 CPU 处理内存中的数据比较运算)。当我们的 IO 优化做到一定阶段之后,降低 CPU 计算也就成为了我们 SQL 优化的重要目标优化方法改变 SQL 执行计划 明确了优化目标之后,我们需要确定达到我们目标的方法。对于 SQL 语句来说,达到上述2个目标的方法其实只有一个,那就是改变 SQL 的执行计划,让他尽量“少走弯路”,尽量通过各种“捷径”来找到我们需要的数据,以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标分析复杂的SQL语句explain 例如: mysql> explain select from (select from ( select * from t3 where id=3952602) a) b; id select_type table type possible_keys key key_len ref rows Extra 1 PRIMARY system NULL NULL NULL NULL 1 2 DERIVED system NULL NULL NULL NULL 1 3 DERIVED t3 const PRIMARY,idx_t3_id PRIMARY 4 1 很显然这条SQL是从里向外的执行,就是从id=3 向上执行.show show tables或show tables from database_name; // 显示当前数据库中所有表的名称 show databases; // 显示mysql中所有数据库的名称 show columns from table_name from database_name; 或MySQL show columns from database_name.table_name; // 显示表中列名称 show grants for user_name@localhost; // 显示一个用户的权限,显示结果类似于grant 命令 show index from table_name; // 显示表的索引 show status; // 显示一些系统特定资源的信息,例如,正在运行的线程数量 show variables; // 显示系统变量的名称和值show processlist; // 显示系统中正在运行的所有进程,也就是当前正在执行的查询。 show table status; // 显示当前使用或者指定的database中的每个表的信息。信息包括表类型和表的最新更新时间 show privileges; // 显示服务器所支持的不同权限 show create database database_name; // 显示create database 语句是否能够创建指定的数据库 show create table table_name; // 显示create database 语句是否能够创建指定的数据库 show engies; // 显示安装以后可用的存储引擎和默认引擎。 show innodb status; // 显示innoDB存储引擎的状态 show logs; // 显示BDB存储引擎的日志 show warnings; // 显示最后一个执行的语句所产生的错误、警告和通知 show errors; // 只显示最后一个执行语句所产生的错误关于enum 存在争议。 对于取值有限且固定的字段,推荐使用enum而非varchar。但是!!其他数据库可能不支持,导致了难于迁移的问题。开启缓存查询 对于完全相同的sql,使用已经存在的执行计划,从而跳过解析和生成执行计划的过程。 应用场景:有一个不经常变更的表,且服务器收到该表的大量相同查询。对于频繁更新的表,查询缓存是不适合的 Mysql 判断是否命中缓存的办法很简单,首先会将要缓存的结果放在引用表中,然后使用查询语句,数据库名称,客户端协议的版本等因素算出一个hash值,这个hash值与引用表中的结果相关联。如果在执行查询时,根据一些相关的条件算出的hash值能与引用表中的数据相关联,则表示查询命中 查询必须是完全相同的(逐字节相同)才能够被认为是相同的。另外,同样的查询字符串由于其它原因可能认为是不同的。使用不同的数据库、不同的协议版本或者不同 默认字符集的查询被认为是不同的查询并且分别进行缓存。 下面sql查询缓存认为是不同的: SELECT * FROM tbl_name Select * from tbl_name 缓存机制失效的场景 如果查询语句中包含一些不确定因素时(例如包含 函数Current()),该查询不会被缓存,不确定因素主要包含以下情况 · 引用了一些返回值不确定的函数 · 引用自定义函数(UDFs)。 · 引用自定义变量。 · 引用mysql系统数据库中的表。 · 下面方式中的任何一种: SELECT ...IN SHARE MODE SELECT ...FOR UPDATE SELECT ...INTO OUTFILE ... SELECT ...INTO DUMPFILE ... SELECT * FROM ...WHERE autoincrement_col IS NULL · 使用TEMPORARY表。 · 不使用任何表。 · 用户有某个表的列级别权限。额外的消耗 如果使用查询缓存,在进行读写操作时会带来额外的资源消耗,消耗主要体现在以下几个方面 · 查询的时候会检查是否命中缓存,这个消耗相对较小 · 如果没有命中查询缓存,MYSQL会判断该查询是否可以被缓存,而且系统中还没有对应的缓存,则会将其结果写入查询缓存 · 如果一个表被更改了,那么使用那个表的所有缓冲查询将不再有效,并且从缓冲区中移出。这包括那些映射到改变了的表的使用MERGE表的查询。一个表可以被许多类型的语句更改,例如INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE。 对于InnoDB而言,事物的一些特性还会限制查询缓存的使用。当在事物A中修改了B表时,因为在事物提交之前,对B表的修改对其他的事物而言是不可见的。为了保证缓存结果的正确性,InnoDB采取的措施让所有涉及到该B表的查询在事物A提交之前是不可缓存的。如果A事物长时间运行,会严重影响查询缓存的命中率 查询缓存的空间不要设置的太大。 因为查询缓存是靠一个全局锁操作保护的,如果查询缓存配置的内存比较大且里面存放了大量的查询结果,当查询缓存失效的时候,会长时间的持有这个全局锁。因为查询缓存的命中检测操作以及缓存失效检测也都依赖这个全局锁,所以可能会导致系统僵死的情况静态表速度更快定长类型和变长类型 CHAR(M)定义的列的长度为固定的,M取值可以为0~255之间,当保存CHAR值时,在它们的右边填充空格以达到指定的长度。当检索到CHAR值时,尾部的空格被删除掉。在存储或检索过程中不进行大小写转换。CHAR存储定长数据很方便,CHAR字段上的索引效率级高,比如定义char(10),那么不论你存储的数据是否达到了10个字节,都要占去10个字节的空间,不足的自动用空格填充。 VARCHAR(M)定义的列的长度为可变长字符串,M取值可以为0~65535之间,(VARCHAR的最大有效长度由最大行大小和使用的字符集确定。整体最大长度是65,532字节)。VARCHAR值保存时只保存需要的字符数,另加一个字节来记录长度(如果列声明的长度超过255,则使用两个字节)。VARCHAR值保存时不进行填充。当值保存和检索时尾部的空格仍保留,符合标准SQL。varchar存储变长数据,但存储效率没有CHAR高。 如果一个字段可能的值是不固定长度的,我们只知道它不可能超过10个字符,把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。空间上考虑,用varchar合适;从效率上考虑,用char合适,关键是根据实际情况找到权衡点。VARCHAR和TEXT、BlOB类型 VARCHAR,BLOB和TEXT类型是变长类型,对于其存储需求取决于列值的实际长度(在前面的表格中用L表示),而不是取决于类型的最大可能尺寸。 BLOB和TEXT类型需要1,2,3或4个字节来记录列值的长度,这取决于类型的最大可能长度。VARCHAR需要定义大小,有65535字节的最大限制;TEXT则不需要。如果你把一个超过列类型最大长度的值赋给一个BLOB或TEXT列,值被截断以适合它。 一个BLOB是一个能保存可变数量的数据的二进制的大对象。4个BLOB类型TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB仅仅在他们能保存值的最大长度方面有所不同。 BLOB 可以储存图片,TEXT不行,TEXT只能储存纯文本文件。 在BLOB和TEXT类型之间的唯一差别是对BLOB值的排序和比较以大小写敏感方式执行,而对TEXT值是大小写不敏感的。换句话说,一个TEXT是一个大小写不敏感的BLOB。 效率来说基本是char>varchar>text,但是如果使用的是Innodb引擎的话,推荐使用varchar代替char char和varchar可以有默认值,text不能指定默认值静态表和动态表 静态表字段长度固定,自动填充,读写速度很快,便于缓存和修复,但比较占硬盘,动态表是字段长度不固定,节省硬盘,但更复杂,容易产生碎片,速度慢,出问题后不容易重建。当只需要一条数据的时候,使用limit 1 表记录中的一行尽量不要超过一个IO单元 区分in和exist select * from 表A where id in (select id from 表B)这句相当于select from 表A where exists(select from 表B where 表B.id=表A.id)对于表A的每一条数据,都执行select * from 表B where 表B.id=表A.id的存在性判断,如果表B中存在表A当前行相同的id,则exists为真,该行显示,否则不显示 区分in和exists主要是造成了驱动顺序的改变(这是性能变化的关键),如果是exists,那么以外层表为驱动表,先被访问,如果是IN,那么先执行子查询。 所以IN适合于外表大而内表小的情况;EXISTS适合于外表小而内表大的情况复杂多表尽量少用join MySQL 的优势在于简单,但这在某些方面其实也是其劣势。MySQL 优化器效率高,但是由于其统计信息的量有限,优化器工作过程出现偏差的可能性也就更多。对于复杂的多表 Join,一方面由于其优化器受限,再者在 Join 这方面所下的功夫还不够,所以性能表现离 Oracle 等关系型数据库前辈还是有一定距离。但如果是简单的单表查询,这一差距就会极小甚至在有些场景下要优于这些数据库前辈。尽量用join代替子查询 虽然 Join 性能并不佳,但是和 MySQL 的子查询比起来还是有非常大的性能优势。 MySQL需要为内层查询语句的查询结果建立一个临时表。然后外层查询语句在临时表中查询记录。查询完毕后,MySQL需要插销这些临时表。所以在MySQL中可以使用连接查询来代替子查询。连接查询不需要建立临时表,其速度比子查询要快。尽量少排序 排序操作会消耗较多的 CPU 资源,所以减少排序可以在缓存命中率高等 IO 能力足够的场景下会较大影响 SQL 的响应时间。 对于MySQL来说,减少排序有多种办法,比如: 上面误区中提到的通过利用索引来排序的方式进行优化 减少参与排序的记录条数 非必要不对数据进行排序尽量避免select * 大多数关系型数据库都是按照行(row)的方式存储,而数据存取操作都是以一个固定大小的IO单元(被称作 block 或者 page)为单位,一般为4KB,8KB… 大多数时候,每个IO单元中存储了多行,每行都是存储了该行的所有字段(lob等特殊类型字段除外)。 所以,我们是取一个字段还是多个字段,实际上数据库在表中需要访问的数据量其实是一样的。 也有例外情况,那就是我们的这个查询在索引中就可以完成,也就是说当只取 a,b两个字段的时候,不需要回表,而c这个字段不在使用的索引中,需要回表取得其数据。在这样的情况下,二者的IO量会有较大差异。尽量少or 当 where 子句中存在多个条件以“或”并存的时候,MySQL 的优化器并没有很好的解决其执行计划优化问题,再加上 MySQL 特有的 SQL 与 Storage 分层架构方式,造成了其性能比较低下,很多时候使用 union all 或者是union(必要的时候)的方式来代替“or”会得到更好的效果。尽量用 union all 代替 union union 和 union all 的差异主要是前者需要将两个(或者多个)结果集合并后再进行唯一性过滤操作,这就会涉及到排序,增加大量的 CPU 运算,加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候,尽量使用 union all 而不是 union。尽量早过滤 在 SQL 编写中同样可以使用这一原则来优化一些 Join 的 SQL。比如我们在多个表进行分页数据查询的时候,我们最好是能够在一个表上先过滤好数据分好页,然后再用分好页的结果集与另外的表 Join,这样可以尽可能多的减少不必要的 IO 操作,大大节省 IO 操作所消耗的时间。避免类型转换 这里所说的“类型转换”是指 where 子句中出现 column 字段的类型和传入的参数类型不一致的时候发生的类型转换: 人为在column_name 上通过转换函数进行转换直接导致 MySQL(实际上其他数据库也会有同样的问题)无法使用索引,如果非要转换,应该在传入的参数上进行转换,由数据库自己进行转换, 如果我们传入的数据类型和字段类型不一致,同时我们又没有做任何类型转换处理,MySQL 可能会自己对我们的数据进行类型转换操作,也可能不进行处理而交由存储引擎去处理,这样一来,就会出现索引无法使用的情况而造成执行计划问题。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL 对于破坏性来说,高并发的 SQL 总是会比低频率的来得大,因为高并发的 SQL 一旦出现问题,甚至不会给我们任何喘息的机会就会将系统压跨。而对于一些虽然需要消耗大量 IO 而且响应很慢的 SQL,由于频率低,即使遇到,最多就是让整个系统响应慢一点,但至少可能撑一会儿,让我们有缓冲的机会。从全局出发优化,而不是片面调整 尤其是在通过调整索引优化 SQL 的执行计划的时候,千万不能顾此失彼,因小失大。尽可能对每一条运行在数据库中的SQL进行 explain 知道 SQL 的执行计划才能判断是否有优化余地,才能判断是否存在执行计划问题。在对数据库中运行的 SQL 进行了一段时间的优化之后,很明显的问题 SQL 可能已经很少了,大多都需要去发掘,这时候就需要进行大量的 explain 操作收集执行计划,并判断是否需要进行优化。尽量避免where子句中对字段进行null值的判断 会导致引擎放弃索引,进而进行全表扫描。 尽量不要给数据库留null值,尽可能地使用not null填充数据库。可以为每个null型的字段设置一个和null对应的实际内容表述。避免在where中使用!=, >, <操作符 否则引擎放弃使用索引,进行全表扫描。常用查询字段建索引避免在where中使用or imagein和not in关键词慎用,容易导致全表扫面 对连续的数值尽量用between通配符查询也容易导致全表扫描避免在where子句中使用局部变量 sql只有在运行时才解析局部变量。而优化程序必须在编译时访问执行计划,这时并不知道变量值,所以无法作为索引的输入项。 image避免在where子句中对字段进行表达式操作 会导致引擎放弃使用索引 image避免在where子句中对字段进行函数操作 image不要where子句的‘=’左边进行函数、算术运算或其他表达式运算 系统可能无法正确使用索引避免update全部字段 只update需要的字段。频繁调用会引起明显的性能消耗,同时带来大量日志。索引不是越多越好 一个表的索引数最好不要超过6个尽量使用数字型字段而非字符型 因为处理查询和连接时会逐个比较字符串的每个字符,而对于数字型而言只需要比较一次就够了。尽可能用varchar/nvarchar代替char/nchar 变长字段存储空间小,对于查询来说,在一个相对较小的字段内搜索效率更高。。。?避免频繁创建和删除临时表,减少系统表资源消耗select into和create table 新建临时表时,如果一次性插入数据量很大,使用select into代替create table,避免造成大量log,以提高速度。 如果数据量不大,为了缓和系统表的资源,先create table,再insert。 拆分大的DELETE和INSERT语句 因为这两个操作是会锁表的,对于高访问量的站点来说,锁表时间内积累的访问数、数据库连接、打开的文件数等等,可能不仅仅让WEB服务崩溃,还会让整台服务器马上挂了。 所以,一定要拆分,使用LIMIT条件休眠一段时间,批量处理。

wangccsy 2019-12-02 01:50:30 0 浏览量 回答数 0

回答

  关于 SQLite 的优化,首先是能用SQL语句的,就不要单笔操作, Cursor 就更是能不用就不用。比如成批的 DELETE/UPDATE ,将条件组装到 SQL 语句,会比使用 CURSOR 一条条的查再删效率要高很多( 若干年前就曾使用存储过程代替单笔操作,将一次批量计算时间从一晚上缩到了一小时以内 )。其次是对操作的优化:对于 INSERT/UPDATE 操作较多时使用事务,如果SELECT操作较多时,使用索引。   结合现在的工作,发现针对操作的优化,下面 这篇文章 可以翻译出来归档。以下为正文:   SQLite 有一个简洁的SQL接口,且以低内存占用著称。现如今, SQLite 已经在 Android 及 iOS 开发中得到广泛的应用。本文主要讨论在 Android 应用如何优化 SQLite 的性能和资源占用。   1, 使用事务( Transaction )   在默认情况下每一个SQL语句都被包一个全新的事务内,比如执行一个如INSERT这样基本的数据库操作,就会放到一个新创建的事务中执行。一次只需要操作一次数据库操作时,让SQLite自己来进行事务管理当然是明智的。但如果一次有大量的操作要做时,比如循环调用INSERT添加时,这样就显得开销过大了,因为每一笔操作都要重新打开、写入,最后再关闭journal文件, 这个文件是临时用来保存数据操作的中间结果,详细内容看这里( 参考 )。   如果明确地在一系列SQL语句前后以 BEGIN TRANSACTION 及 END TRANSACTION 这样显示地使用事务就可以避免上面的情况。对于那些不会改变数据的操作,这样的方式也同样可以提速(好似数据库操作中单笔的操作效率将远低于批次操作,如果用SQL语句可以搞定的事,就不可使用Cursor进行操作)。   注明:除了发起事务外,你必须还要负责对事务的提交和回滚操作。   在Android应用开发中可以使用类似如下的方式使用 BEGIN TRANSACTION 及 END TRANSACTION :   db.beginTransaction(); try{ for(int i =0; i< LENGTH ; i++,sequenceNum++) { // execute SQL } db.setTransactionSuccessful();// marks a commit } finally{ db.endTransaction(); }   2. 使用索引   如果没有在数据库使用索引,当你在一个没有排序的数据表中使用映射查询(projection query)搜索时,无可避免的要执行一个全序列查找。这种情况通常并不是什么问题,每种数据库,包括SQLite都会为数据集执行索引来降低查找时间。   索引维护着一个表中某一列或某几列的顺序,这样就可以快速定位到一组值,而不用扫遍全表。所有的索引信息会被保存在一个独立的索引表中,所以会产生额外的空间占用,不过绝对物超所值,特别是当你会在数据库中进行大量的读及搜索操作时。   SQLite会自动为每一个UNIQUE栏位创建索引,包括主键(Primary Key)栏位,另外也可以通过CREATE INDEX进行显示地创建。   注:如果你的查询太复杂而无法使用所创建的索引,那你就要好好想想你数据库的结构了。   3. 在Where分支中使用限定符   如果以字串拼接出SQL语句的Where,莫不如使用SQLite的query操作带上'?'来编译查询。以下是它的好处:   a. 有利于SQLite缓存这些查询。   b. 可以避免达到SQLite缓存的上限。使用字串拼接Where的查询,每一个都被视为不同的查询,这就容易达到缓存的上限。   c. 可以避免非法的SQL注入。    “答案来源于网络,供您参考” 希望以上信息可以帮到您!

牧明 2019-12-02 02:17:55 0 浏览量 回答数 0

问题

X亿级数据检索速度优化难题

吴孟桥 2019-12-01 19:52:15 1195 浏览量 回答数 1

问题

MySQL中复合索引中列的顺序对性能的影响,数据库报错

python小菜菜 2020-06-01 19:30:19 0 浏览量 回答数 1

回答

ReMySQL官方管理工具上线啦,快来体验! 用RDS的初衷是省心,不需要自己维护mysql数据库,其实看到RDS控制面板里有优化的一些监控选项,但是我想说的是如果RDS控制面板也好,IDB也罢,如果只停留在(更多RDS数据库性能优化相关的数据,便于开发人员、SA、DBA优化数据库。)那依然是把RDS当作给程序员,开发人员,大公司(有能力雇开发人员)用的,而不是给普通站长用的. 希望能站在普通站长的角度,看看能不能有更加方便的工具,提示,或者引导,指导,普通站长(没开发能力的)去优化RDS数据库呢? 我虽然很喜欢阿里云的产品,包括ECS,RDS,OSS等等,但是这些产品说实话都是停留在面向于有开发能力,有windows,liunx服务器环境实施操作能力的站长,不过相对于其他产品而言ECS的第三方工具以及第三方合作伙伴生态环境相对来说好很多,教程也比较多,如果遇到虽然不懂怎么操作,但是善于学习的站长来说还是可以的,RDS导入数据库应该说也勉强能够接受,但是RDS的优化我反正是看不懂了,当然也不敢轻易的去动设置选项,也没钱找开发人员,或者数据库维护人员帮我优化了! OSS就更惨了,找不到合适的discuz x3.1插件不说,连几十G数据想从upyun搬家到青岛oss节点,都找不到合适的解决方案. ------------------------- ReMySQL官方管理工具上线啦,快来体验! 貌似查询数量只能3000条,但是如果我想修改超过3000条以上的数据怎么办? ------------------------- 回12楼钟隐的帖子 以前一直是用phpmyadmin来管理mysql数据库的,既然你们让我们的phpmyadmin say NO,那你们得给我们一个理由让我们去say NO,假设phpmyadmin能做到的事情你们无法做到,我们又为什么要去对phpmyadmin say NO,您也给我一个理由! 不要说想像不出来什么场景,既然一个事物要代替另一个事物,你必须要满足建立在拥有代替那个事物全部功能基础之上的,也就是说他能做到的,你们都能做到,他做不到的你们还能做到,不然用户为什么要对原来的事物say no? 开发人员可能无法站在普通站长的视角去看问题,因为我们无法站长开发人员的视角去处理问题,因为我们是普通站长,我们不懂SQL语句 我是不敢轻易在phpmyadmin里运行SQL语句的,万一错了,导致后果很严重,我们菜鸟就真的束手无策了,我也不敢说很懂phpmyadmin如何使用,至少我从来没用过,我看一下,我能简单的对我的数据库里的内容进行修改! 我用的是discuz,在phpmyadmin里左侧可以看到各种discuz数据库里的表单,比如记录帖子的表单,比如记录用户的表单,我在phpmyadmin里是可以把某一个帖子的数据调出来修改的! 比如这个帖子的数据是在第9000多个,我虽然你不懂语句,我可以在phpmyadmin里查看第多少页到多少页的数据,我让他一页显示多少个,然后再估算一下多少页之间可以找到这帖子的数据,我就能找到这个帖子的数据,然后对这个数据进行修改! 可是在你们的这个工具里,我只能查看到3000条,可是3000条之后的呢?我不是说要一次性查看几万条,几十万条,可是如果数据如果是有编号的从1-50万,如果我要查看这50万条数据中最后的3000条我要如何做? 其实你们错误的理解我们的需求,你认为我们是要批量修改超过3000条的数据,其实是我在查看一个表的时候这个表有几十万条数据,问题是我无法做到查看排序在3000条以后的数据.....,看来看去就只能看到前3000条,问题是我要改后面的数据 您看一下用户的反馈都是对翻页功能,查询数据的功能吐槽! 我想他的问题应该跟我一样,想通过翻页,查询找到自己想要的数据是很痛苦的! 最倒霉的是把phpmyadmin里这些功能给限制不让用了!

solidedge 2019-12-01 23:27:53 0 浏览量 回答数 0

回答

ReMySQL官方管理工具上线啦,快来体验! 用RDS的初衷是省心,不需要自己维护mysql数据库,其实看到RDS控制面板里有优化的一些监控选项,但是我想说的是如果RDS控制面板也好,IDB也罢,如果只停留在(更多RDS数据库性能优化相关的数据,便于开发人员、SA、DBA优化数据库。)那依然是把RDS当作给程序员,开发人员,大公司(有能力雇开发人员)用的,而不是给普通站长用的. 希望能站在普通站长的角度,看看能不能有更加方便的工具,提示,或者引导,指导,普通站长(没开发能力的)去优化RDS数据库呢? 我虽然很喜欢阿里云的产品,包括ECS,RDS,OSS等等,但是这些产品说实话都是停留在面向于有开发能力,有windows,liunx服务器环境实施操作能力的站长,不过相对于其他产品而言ECS的第三方工具以及第三方合作伙伴生态环境相对来说好很多,教程也比较多,如果遇到虽然不懂怎么操作,但是善于学习的站长来说还是可以的,RDS导入数据库应该说也勉强能够接受,但是RDS的优化我反正是看不懂了,当然也不敢轻易的去动设置选项,也没钱找开发人员,或者数据库维护人员帮我优化了! OSS就更惨了,找不到合适的discuz x3.1插件不说,连几十G数据想从upyun搬家到青岛oss节点,都找不到合适的解决方案. ------------------------- ReMySQL官方管理工具上线啦,快来体验! 貌似查询数量只能3000条,但是如果我想修改超过3000条以上的数据怎么办? ------------------------- 回12楼钟隐的帖子 以前一直是用phpmyadmin来管理mysql数据库的,既然你们让我们的phpmyadmin say NO,那你们得给我们一个理由让我们去say NO,假设phpmyadmin能做到的事情你们无法做到,我们又为什么要去对phpmyadmin say NO,您也给我一个理由! 不要说想像不出来什么场景,既然一个事物要代替另一个事物,你必须要满足建立在拥有代替那个事物全部功能基础之上的,也就是说他能做到的,你们都能做到,他做不到的你们还能做到,不然用户为什么要对原来的事物say no? 开发人员可能无法站在普通站长的视角去看问题,因为我们无法站长开发人员的视角去处理问题,因为我们是普通站长,我们不懂SQL语句 我是不敢轻易在phpmyadmin里运行SQL语句的,万一错了,导致后果很严重,我们菜鸟就真的束手无策了,我也不敢说很懂phpmyadmin如何使用,至少我从来没用过,我看一下,我能简单的对我的数据库里的内容进行修改! 我用的是discuz,在phpmyadmin里左侧可以看到各种discuz数据库里的表单,比如记录帖子的表单,比如记录用户的表单,我在phpmyadmin里是可以把某一个帖子的数据调出来修改的! 比如这个帖子的数据是在第9000多个,我虽然你不懂语句,我可以在phpmyadmin里查看第多少页到多少页的数据,我让他一页显示多少个,然后再估算一下多少页之间可以找到这帖子的数据,我就能找到这个帖子的数据,然后对这个数据进行修改! 可是在你们的这个工具里,我只能查看到3000条,可是3000条之后的呢?我不是说要一次性查看几万条,几十万条,可是如果数据如果是有编号的从1-50万,如果我要查看这50万条数据中最后的3000条我要如何做? 其实你们错误的理解我们的需求,你认为我们是要批量修改超过3000条的数据,其实是我在查看一个表的时候这个表有几十万条数据,问题是我无法做到查看排序在3000条以后的数据.....,看来看去就只能看到前3000条,问题是我要改后面的数据 您看一下用户的反馈都是对翻页功能,查询数据的功能吐槽! 我想他的问题应该跟我一样,想通过翻页,查询找到自己想要的数据是很痛苦的! 最倒霉的是把phpmyadmin里这些功能给限制不让用了!

solidedge 2019-12-02 02:57:39 0 浏览量 回答数 0

回答

hk.backMoney这个字段会显示的是最大的hk.backTime对应的数据吗?因为你用了 Group By 所以显示的是同一个 userInfoId 下最大的那个 hk.backTime多个字段使用聚合函数之后,如果没有对其它的字段进行分组,这时候只有一条,其他字段是怎么取的?其他的字段的取法和你使用的数据库具体实现相关,可能是默认排序,也有可能是随机返回,所以一般来说在聚合查询中, Select 非聚合字段没有意义。如果想要实现类似取出某个用户最近的一条操作记录的话,那么就需要在外面再包一层查询语句。

我的中国 2019-12-02 01:34:01 0 浏览量 回答数 0

问题

DRDS 错误代码如何解决?

猫饭先生 2019-12-01 21:21:21 7993 浏览量 回答数 0

问题

业务逻辑写在数据库还是自身应用程序?

蛮大人123 2019-12-01 20:02:37 1552 浏览量 回答数 1

问题

【RDS教程】专业DBA速成 - CPU优化篇

rds-pd 2019-12-01 21:59:13 15591 浏览量 回答数 3

问题

MySQL 数据库如何设置是否大小写敏感?

云栖大讲堂 2019-12-01 21:32:23 4342 浏览量 回答数 0

回答

如果指定ORDER BY语句,数据库将对行进行排序,并按请求的顺序返回。 但是,如果该顺序不是确定性的,即值重复,则在每个具有相同值的组中,由于很多可以改变顺序的因素(并行的HASH连接),该顺序是“随机的”。   确保确定性顺序的唯一方法是在ORDER BY子句中包含保证的唯一列或列组(例如主键)。

1248780489098131 2020-01-09 09:15:58 0 浏览量 回答数 0

问题

在选择记录时修改记录中键的最佳解决方案

保持可爱mmm 2019-12-01 21:59:45 2 浏览量 回答数 1

问题

MaxCompute快速入门:运行SQL

行者武松 2019-12-01 22:01:39 1282 浏览量 回答数 0

问题

PDO是如何处理SQL语句中对字段名以及表名的转义

落地花开啦 2019-12-01 19:52:45 1504 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SSL证书 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 2020中国云原生 阿里云云栖号