mysql not exists 效率高_mysql not in、left join、IS NULL、NOT EXISTS 效率问题记录

最新推荐文章于 2023-08-22 11:38:02 发布
最新推荐文章于 2023-08-22 11:38:02 发布
阅读量773 收藏 1
点赞数
文章标签： mysql not exists 效率高
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_42419782/article/details/113339843
版权

语句一：select count(*) from A where A.a not in (select a from B)

语句二：select count(*) from A left join B on A.a = B.a where B.a is null

语句三：select count(*) from A where not exists (select a from B where A.a = B.a)

知道以上三条语句的实际效果是相同的已经很久了，但是一直没有深究其间的效率对比。一直感觉上语句二是最快的。 今天工作上因为要对一个数千万行数据的库进行数据清除，需要删掉两千多万行数据。大量的用到了以上三条语句所要实现的功能。本来用的是语句一，但是结果是执行速度1个小时32分，日志文件占用21GB。时间上虽然可以接受，但是对硬盘空间的占用确是个问题。因此将所有的语句一都换成语句二。本以为会更快。没想到执行40多分钟后，第一批50000行都没有删掉，反而让SQL SERVER崩溃掉了，结果令人诧异。试了试单独执行这条语句，查询近一千万行的表，语句一用了4秒，语句二却用了18秒，差距很大。语句三的效率与语句一接近。

第二种写法是大忌，应该尽量避免。第一种和第三种写法本质上几乎一样。

假设buffer pool足够大，写法二相对于写法一来说存在以下几点不足： (1)left join本身更耗资源(需要更多资源来处理产生的中间结果集) (2)left join的中间结果集的规模不会比表A小 (3)写法二还需要对left join产生的中间结果做is null的条件筛选，而写法一则在两个集合join的同时完成了筛选，这部分开销是额外的

这三点综合起来，在处理海量数据时就会产生比较明显的区别(主要是内存和CPU上的开销)。我怀疑楼主在测试时buffer pool可能已经处于饱和状态，这样的话，写法二的那些额外开销不得不借助磁盘上的虚拟内存，在SQL Server做换页时，由于涉及到较慢的I/O操作因此这种差距会更加明显。

关于日志文件过大，这也是正常的，因为删除的记录多嘛。可以根据数据库的用途考虑将恢复模型设为simple，或者在删除结束后将日志truncate掉并把文件shrink下来。

因为以前曾经作过一个对这个库进行无条件删除的脚本，就是要删除数据量较大的表中的所有数据，但是因为客户要求，不能使用truncate table，怕破坏已有的库结构。所以只能用delete删，当时也遇到了日志文件过大的问题，当时采用的方法是分批删除，在SQL2K中用set rowcount @chunk，在SQL2K5中用delete top @chunk。这样的操作不仅使删除时间大大减少，而且让日志量大大减少，只增长了1G左右。 但是这次清除数据的工作需要加上条件，就是delete A from A where ....后面有条件的。再次使用分批删除的方法，却已经没效果了。 不知您知不知道这是为什么。

mysql not in 和 left join 效率问题记录

首先说明该条sql的功能是查询集合a不在集合b的数据。 not in的写法

select add_tb.RUID

from (select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime>'2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) add_tb

where add_tb.RUID

not in (select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime

)

返回444行记录用时 0.07sec explain 结果

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows |

Extra |

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 452 |

Using where |

| 3 | DEPENDENT SUBQUERY | UserMsg | index_subquery | RUID,SubjectID,CreateTime | RUID | 96 | func | 2 |

Using index; Using where |

| 2 | DERIVED | UserMsg | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1857 |

Using where; Using temporary |

+----+--------------------+------------+----------------+---------------------------+------------+---------+------+------+--

----------------------------+

分析:该条查询速度快原因为id=2的sql查询出来的结果比较少，所以id=1sql所以运行速度比较快，id=2的使用了临时表，不知道这个时候是否使用索引？ 其中一种left join

select a.ruid,b.ruid

from(select distinct RUID

from UserMsg

where SubjectID =12

and CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) a left join (

select distinct RUID

from UserMsg

where SubjectID =12 and CreateTime< '2009-8-14 15:30:00'

) b on a.ruid = b.ruid

where b.ruid is null

返回444行记录用时 0.39sec

explain 结果

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 452 |

|

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1112 | Using where; Not exists

|

| 3 | DERIVED | UserMsg | ref | SubjectID,CreateTime | SubjectID | 5 | | 6667 | Using where; Using

temporary |

| 2 | DERIVED | UserMsg | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1838 | Using where; Using

temporary |

+----+-------------+------------+-------+----------------------+------------+---------+------+------+-----------------------

-------+

分析:使用了两个临时表，并且两个临时表做了笛卡尔积，导致不能使用索引并且数据量很大

另外一种left join

复制代码 代码如下:

select distinct a.RUID

from UserMsg a

left join UserMsg b

on a.ruid = b.ruid

and b.subjectID =12 and b.createTime < '2009-8-14 15:30:00'

where a.subjectID =12

and a.createTime >= '2009-8-14 15:30:00'

and a.createtime <='2009-8-17 16:00:00'

and b.ruid is null;

返回444行记录用时 0.07sec

explain 结果

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

| 1 | SIMPLE | a | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1839 | Using where;

Using temporary |

| 1 | SIMPLE | b | ref | RUID,SubjectID,CreateTime | RUID | 96 | dream.a.RUID | 2 | Using where;

Not exists; Distinct |

+----+-------------+-------+-------+---------------------------+------------+---------+--------------+------+---------------

--------------------+

分析：两次查询都是用上了索引，并且查询时同时进行的，所以查询效率应该很高

使用not exists的sql

复制代码 代码如下:

select distinct a.ruid

from UserMsg a

where a.subjectID =12

and a.createTime >= '2009-8-14 15:30:00'

and a.createTime <='2009-8-17 16:00:00'

and not exists (

select distinct RUID

from UserMsg

where subjectID =12 and createTime < '2009-8-14 15:30:00'

and ruid=a.ruid

)

返回444行记录用时 0.08sec

explain 结果

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

| 1 | PRIMARY | a | range | SubjectID,CreateTime | CreateTime | 9 | NULL | 1839 | Using

where; Using temporary |

| 2 | DEPENDENT SUBQUERY | UserMsg | ref | RUID,SubjectID,CreateTime | RUID | 96 | dream.a.RUID | 2 | Using

where |

+----+--------------------+---------+-------+---------------------------+------------+---------+--------------+------+------

------------------------+

分析：同上基本上是一样的，只是分解了2个查询顺序执行，查询效率低于第3个

为了验证数据查询效率，将上述查询中的subjectID =12的限制条件去掉，结果统计查询时间如下

0.20s

21.31s

0.25s

0.43s

laserhe帮忙分析问题总结

复制代码 代码如下:

select a.ruid,b.ruid

from( select distinct RUID

from UserMsg

where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00'

) a left join UserMsg b

on a.ruid = b.ruid

and b.createTime < '2009-8-14 15:30:00'

where b.ruid is null;

执行时间0.13s

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 |

|

| 1 | PRIMARY | b | ref | RUID,CreateTime | RUID | 96 | a.RUID | 2 | Using where; Not exists

|

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3553 | Using where; Using

temporary |

+----+-------------+------------+-------+-----------------+------------+---------+--------+------+--------------------------

----+

执行效率类似与not in的效率

数据库优化的基本原则：让笛卡尔积发生在尽可能小的集合之间，mysql在join的时候可以直接通过索引来扫描，而嵌入到子查询里头，查询规

划器就不晓得用合适的索引了。

一个SQL在数据库里是这么优化的：首先SQL会分析成一堆分析树，一个树状数据结构，然后在这个数据结构里，查询规划器会查找有没有合适

的索引，然后根据具体情况做一个排列组合，然后计算这个排列组合中的每一种的开销(类似explain的输出的计算机可读版本)，然后比较里

面开销最小的，选取并执行之。那么：

explain select a.ruid,b.ruid from(select distinct RUID from UserMsg where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00' ) a left join UserMsg b on a.ruid = b.ruid and b.createTime < '2009-8-14 15:30:00'

where b.ruid is null;

和

explain select add_tb.RUID

-> from (select distinct RUID

-> from UserMsg

-> where CreateTime>'2009-8-14 15:30:00'

-> and CreateTime<='2009-8-17 16:00:00'

-> ) add_tb

-> where add_tb.RUID

-> not in (select distinct RUID

-> from UserMsg

-> where CreateTime

-> );

explain

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 | Using where

|

| 3 | DEPENDENT SUBQUERY | UserMsg | index_subquery | RUID,CreateTime | RUID | 96 | func | 2 | Using index;

Using where |

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3509 | Using where;

Using temporary |

+----+--------------------+------------+----------------+-----------------+------------+---------+------+------+------------

------------------+

开销是完全一样的，开销可以从 rows 那个字段得出(基本上是rows那个字段各个行的数值的乘积，也就是笛卡尔积)

但是呢：下面这个：

explain select a.ruid,b.ruid from(select distinct RUID from UserMsg where CreateTime >= '2009-8-14 15:30:00'

and CreateTime<='2009-8-17 16:00:00' ) a left join ( select distinct RUID from UserMsg where createTime < '2009-8-14

15:30:00' ) b on a.ruid = b.ruid where b.ruid is null;

执行时间21.31s

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra

|

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 1248 |

|

| 1 | PRIMARY | | ALL | NULL | NULL | NULL | NULL | 30308 | Using where; Not exists

|

| 3 | DERIVED | UserMsg | ALL | CreateTime | NULL | NULL | NULL | 69366 | Using where; Using temporary

|

| 2 | DERIVED | UserMsg | range | CreateTime | CreateTime | 9 | NULL | 3510 | Using where; Using temporary

|

+----+-------------+------------+-------+---------------+------------+---------+------+-------+-----------------------------

-+

我就有些不明白

为何是四行

并且中间两行巨大无比

按理说

查询规划器应该能把这个查询优化得跟前面的两个一样的

(至少在我熟悉的pgsql数据库里我有信心是一样的)

但mysql里头不是

所以我感觉查询规划器里头可能还是糙了点

我前面说过优化的基本原则就是，让笛卡尔积发生在尽可能小的集合之间

那么上面最后一种写法至少没有违反这个原则

虽然b 表因为符合条件的非常多，基本上不会用索引

但是并不应该妨碍查询优化器看到外面的join on条件，从而和前面两个SQL一样，选取主键进行join

不过我前面说过查询规划器的作用

理论上来讲

遍历一遍所有可能，计算一下开销

是合理的

我感觉这里最后一种写法没有遍历完整所有可能

可能的原因是子查询的实现还是比较简单？

子查询对数据库的确是个挑战

因为基本都是递归的东西

所以在这个环节有点毛病并不奇怪

其实你仔细想想，最后一种写法无非是我们第一种写法的一个变种，关键在表b的where 条件放在哪里

放在里面，就不会用索引去join

放在外面就会

这个本身就是排列组合的一个可能

详细出处参考：http://www.jb51.net/article/29122.htm

小爽无敌
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL中的in,exists,not in,not exists查询过程对比及结论
12-14
MySQL优化之in,exists,not in,not exists的区别in与existsin查询过程结论：exists查询过程：结论：not in与not existsnot in查询过程：结论：not exists查询过程：结论： 首先我们使用两个用户表作为实例 insert into A (id,username) values (1,'张三'); insert into A (id,username) values (2,'李四'); insert into B (id,phone) values (1,'13188888888'); insert into B (id,phone
join left 大数据_大数据量下not in, not exists, left join的比较
weixin_42357618的博客
01-14 380
/*IN、EXISTS和LEFT JOIN，NOT IN、NOT EXISTS和INNER JOIN在存在与不存在的查询效率*/IF OBJECT_ID('A') IS NOT NULLDROP TABLE AGOCREATE TABLE A(ID INT)GOIF OBJECT_ID('B') IS NOT NULLDROP TABLE BGOCREATE TABLE B(ID INT)GODE...
JOIN、IN、EXISTS效率
学留痕
09-19 1292
EXISTS、IN与JOIN，都可以用来实现形如“查询A表中在（或不在）B表中的记录”的查询逻辑。 在查询的两个表大小相当的情况下，3种查询方式的执行时间通常是： EXISTS <= IN <= JOIN NOT EXISTS <= NOT IN <= LEFT JOI
MySQL联表查询基本操作之left-join常见的坑
01-19
概述 对于中小体量的项目而言，联表查询是再常见不过的操作了，尤其是在做报表的时候。然而校对数据的时候，您发现坑了吗？本篇文章就 mysql 常用联表查询复现常见的坑。 基础环境 建表语句 DROP TABLE IF EXISTS `role`; CREATE TABLE `role` ( `id` int(11) NOT NULL AUTO_INCREMENT, `role_name` VARCHAR(50) DEFAULT NULL COMMENT '角色名', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMME
mysql not in、left join、IS NULL、NOT EXISTS 效率问题记录
12-15
NOT IN、JOIN、IS NULL、NOT EXISTS效率对比 语句一：select count(*) from A where A.a not in (select a from B) 语句二：select count(*) from A left join B on A.a = B.a where B.a is null 语句三：select count(*) from A where not exists (select a from B where A.a = B.a) 知道以上三条语句的实际效果是相同的已经很久了，但是一直没有深究其间的效率对比。一直感觉上语句二是最快的。 今天
关于left join ... is null 的奇怪思路
laozaoxiaowanzi的博客
04-13 2077
虽然题目有点拗口难懂，不知我到底在解决什么问题。我通过例子的方法来说明，就会一目了然了。 最近在做的一个需求，其中一部分要求是：查询出有过什么什么的客户且过滤掉什么的客户，其实就是各种表的联结再加上一些过滤条件。这都不重要，重要的是，这两个过滤条件我写的很有问题。 如下： 假如有一个表tb_ftc（不是真实业务场景的表） c_id ch_no c_st ... 01023 1 -1 02345 3 2 13132 2 ..
数据库sql语句的exists总结
fantaxy025025的专栏
08-11 1261
数据库sql语句的exists总结 sql exists in 学习   先来比较下语法： --deals=交易表，areas=地域表，例如香港；我们的目的：查看有交易的地域 select * from areas where id in (select city_id from deals); select * from areas where id in   (select city...
sql中 in , not in , exists , not exists效率分析
jamesge的博客
09-24 4584
in和exists执行时，in是先执行子查询中的查询，然后再执行主查询。而exists查询它是先执行主查询，即外层表的查询，然后再执行子查询。 exists 和 in 在执行时效率单从执行时间来说差不多，exists要稍微优于in。在使用时一般应该是用exists而不用in 如果子查询得出的结果集记录较少，主查询中的表较大且又有索引时应该用in,反之如果外层的主查询记录较少，子查询中的表大，又有索引时使用exists。IN时不对NULL进行处理。 not exists 和 not in...
not in效率低（MySQL NOT EXIST优化、Not IN优化）
q_1092535160的博客
08-22 1440
仅作为学习笔SQL开发中为什么要尽量避免使用 IN 和 NOT IN 呢记，供大家参考。
【SQL开发实战技巧】系列（六）：从执行计划看NOT IN、NOT EXISTS 和 LEFT JOIN效率，记住内外关联条件不要乱放
热门推荐
赵延东的一亩三分地
02-08 9万+
从执行计划看NOT IN、NOT EXISTS 和 LEFT JOIN效率，还是那就话，别死记网上结论、在使用内外关联时，特别是简写方式时记住关联条件不要乱放！【SQL开发实战技巧】这一系列博主当作复习旧知识来进行写作，毕竟SQL开发在数据分析场景非常重要且基础，面试也会经常问SQL开发和调优经验，相信当我写完这一系列文章，也能再有所收获，未来面对SQL面试也能游刃有余~。
解析mysql left( right ) join使用on与where筛选的差异
01-21
有这样的一个问题mysql查询使用mysql中left(right)join筛选条件在on与where查询出的数据是否有差异。可能只看着两个关键字看不出任何的问题。那我们使用实际的例子来说到底有没有差异。例如存在两张表结构表结构1复制代码 代码如下:drop table if EXISTS A;  CREATE TABLE A (    ID int(1) NOT NULL,    PRIMARY KEY  (ID)  ) ENGINE=MyISAM DEFAULT CHARSET=latin1;  表结构2复制代码 代码如下:drop table if EXISTS B;  CREATE T
MySQL的LEFT JOIN表连接的进阶学习教程
12-15
LEFT JOIN的主表 这里所说的主表是指在连接查询里MySQL以哪个表为主进行查询。比如说在LEFT JOIN查询里，一般来说左表就是主表，但这只是经验之谈，很多时候经验主义是靠不住的，为了说明问题，先来个例子，建两个演示用的表categories和posts： CREATE TABLE IF NOT EXISTS `categories` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `name` varchar(15) NOT NULL, `created` datetime NOT NULL, PRIMARY KEY (`id`)
mysql exists与not exists实例详解
01-21
mysql exists与not exists实例详解 tableA |column1 | column1 |column3 | tableb |column1 | column1 |column3 | 要查询 tableA 的数据,条件是是 tableA.column1 不在 tableB 的 tableB.column2 中 也就是要得到类似以下语句的效果(not in 效果不完全等同于 not exists , 如果子查询中出现空记录, 则整个查询语句不会返回数据) SELECT a.* FROM tableA a WHERE a.column1 not in (
MySQL: mysql is not running but lock exists 的解决方法
12-15
启动MySQL出错，查看了下状态，发现提示MySQL is not running,but lock exists： 一个网友说可能和log文件有关，于是将log文件给移除了，再重启MySQL终于OK了找了下资料，基本上都是说： 代码如下: # chown -R mysql:mysql /var/lib/mysql # rm /var/lock/subsys/mysql # service mysql restart 执行完发现还是这个提示。 因为是在cPanel服务器上，所以又通过命令： 代码如下: # yum remove mysql mysql-server 将mysql卸载了，
node-v10.22.0-darwin-x64.tar.xz
最新发布
05-03
Node.js，简称Node，是一个开源且跨平台的JavaScript运行时环境，它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立，旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎，可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型，这使得它非常适合处理大量并发连接，从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外，Node.js使用了模块化的架构，通过npm（Node package manager，Node包管理器）,社区成员可以共享和复用代码，极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展，它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等，因此，开发者可以用JavaScript编写全栈应用程序，这一点大大提高了开发效率和便捷性。 在实践中，许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台，如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能，简化了开发流程，并且能更快地响应市场需求。
基于JAVA的物流管理系统的源码设计与实现.zip
05-03
毕业设计-->物流管理系统的设计与实现（Java版本） 采用Struts2+hibernate+Oracle10g+Tomcat 涉及车辆管理，配送点管理，运输方式管理，订单管理，员工管理，用户管理，部门管理，权限管理，角色管理等基础管理功能。
基于VB+access实现的成绩分析统计系统(论文+源代码).zip
05-03
基于VB+access实现的成绩分析统计系统(论文+源代码) 【适用人群】：适用于希望学习不同技术领域的小白或进阶学习者。可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。
node-v10.14.2-linux-x64.tar.xz
05-03
Node.js，简称Node，是一个开源且跨平台的JavaScript运行时环境，它允许在浏览器外运行JavaScript代码。Node.js于2009年由Ryan Dahl创立，旨在创建高性能的Web服务器和网络应用程序。它基于Google Chrome的V8 JavaScript引擎，可以在Windows、Linux、Unix、Mac OS X等操作系统上运行。 Node.js的特点之一是事件驱动和非阻塞I/O模型，这使得它非常适合处理大量并发连接，从而在构建实时应用程序如在线游戏、聊天应用以及实时通讯服务时表现卓越。此外，Node.js使用了模块化的架构，通过npm（Node package manager，Node包管理器）,社区成员可以共享和复用代码，极大地促进了Node.js生态系统的发展和扩张。 Node.js不仅用于服务器端开发。随着技术的发展，它也被用于构建工具链、开发桌面应用程序、物联网设备等。Node.js能够处理文件系统、操作数据库、处理网络请求等，因此，开发者可以用JavaScript编写全栈应用程序，这一点大大提高了开发效率和便捷性。 在实践中，许多大型企业和组织已经采用Node.js作为其Web应用程序的开发平台，如Netflix、PayPal和Walmart等。它们利用Node.js提高了应用性能，简化了开发流程，并且能更快地响应市场需求。
ASP+ACCESS网上购物系统设计(源代码+设计说明书+调研报告).zip
05-03
ASP+ACCESS网上购物系统设计(源代码+设计说明书+调研报告).zip

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值