当前位置:

首页 > 编程开发 > mysql临时表怎么使用

mysql临时表怎么使用

在mysql中,临时表指的是临时使用的一张表,是用于存储一些中间结果集的表;临时表只在当前连接可见,当关闭连接时,Mysql会自动删除表并释放所有空间。本教程操作环境:windows7系统、mysql8版本、DellG3电脑。临时表,是临时使用的一张表。临时表是MySQL用于存储一些中间结果集的表,临时表只在当前连接可见,当关闭连接时,Mysql会自动删除表并释放所有空间。使用其他MySQL客户端程序连接MySQL数据库服务器来创建临时表,那么只有在关闭客户端程序时才会销毁临时表,当然也可以手动删除。注:

本文目录

    在mysql中,临时表指的是临时使用的一张表,是用于存储一些中间结果集的表;临时表只在当前连接可见,当关闭连接时,Mysql会自动删除表并释放所有空间。

    本教程操作环境:windows7系统、mysql8版本、Dell G3电脑。

    临时表,是临时使用的一张表。

    临时表是MySQL用于存储一些中间结果集的表,临时表只在当前连接可见,当关闭连接时,Mysql会自动删除表并释放所有空间。

    使用其他MySQL客户端程序连接MySQL数据库服务器来创建临时表,那么只有在关闭客户端程序时才会销毁临时表,当然也可以手动删除。

    注:临时表在MySQL 3.23版本中添加,如果你的MySQL版本低于 3.23版本就无法使用MySQL的临时表。不过现在一般很少有再使用这么低版本的MySQL数据库服务了

    MySQL中的两种临时表

    外部临时表

    通过CREATE TEMPORARY TABLE 创建的临时表,这种临时表称为外部临时表。这种临时表只对当前用户可见,当前会话结束的时候,该临时表会自动关闭。这种临时表的命名与非临时表可以同名(同名后非临时表将对当前会话不可见,直到临时表被删除)。

    内部临时表

    内部临时表是一种特殊轻量级的临时表,用来进行性能优化。这种临时表会被MySQL自动创建并用来存储某些操作的中间结果。这些操作可能包括在优化阶段或者执行阶段。这种内部表对用户来说是不可见的,但是通过EXPLAIN或者SHOW   STATUS可以查看MYSQL是否使用了内部临时表用来帮助完成某个操作。内部临时表在SQL语句的优化过程中扮演着非常重要的角色, MySQL中的很多操作都要依赖于内部临时表来进行优化。但是使用内部临时表需要创建表以及中间数据的存取代价,所以用户在写SQL语句的时候应该尽量的去避免使用临时表。

    内部临时表有两种类型:

    • 一种是HEAP临时表,这种临时表的所有数据都会存在内存中,对于这种表的操作不需要IO操作。

    • 另一种是OnDisk临时表,顾名思义,这种临时表会将数据存储在磁盘上。OnDisk临时表用来处理中间结果比较大的操作。

    如果HEAP临时表存储的数据大于MAX_HEAP_TABLE_SIZE,HEAP临时表将会被自动转换成OnDisk临时表。

    OnDisk临时表在5.7中可以通过INTERNAL_TMP_DISK_STORAGE_ENGINE系统变量选择使用MyISAM引擎或者InnoDB引擎。

    外部临时表的常见用法

    外部临时表是通过CREATE TEMPORARY TABLE及DROP TABLE来操作的,但是SHOW TABLES命令显示数据表列表时,你将无法看到自己创建的临时表的。并且在退出当前会话后,临时表就会被自动销毁。当然也可以手动(DROP TABLE)销毁。

    1、引擎类型:只能是:memory(heap)、myisam、merge、innodb ,不支持mysql cluster(簇)。

    2、外部临时表使用时注意几点:

    1)、自己所用的数据库账号要有建立临时表的权限;

    2)、在同一条sql中,不能关联2次相同的临时表,不然,就会报如下错误;

    mysql> select * from temp_table, temp_table as t2;
      error 1137: can't reopen table: 'temp_table'

    3)、临时表在建立连接时可见,关闭时会清除空间,删除临时表;

    4)、show tables 不会列出临时表;

    5)、不能使用rename重命名临时表。但是,你可以alter table代替:只能使用alter table old_tp_table_name rename new_tp_table_name;

    6)、影响使用replication功能;

    7)、如果你为一个表声明了别名,当你指向这个表的时候,就必须使用这个别名。见《MySQL 多表关联更新及删除》

    示例:

    mysql> CREATE TEMPORARY TABLE SalesSummary (
        -> product_name VARCHAR(50) NOT NULL
        -> , total_sales DECIMAL(12,2) NOT NULL DEFAULT 0.00
        -> , avg_unit_price DECIMAL(7,2) NOT NULL DEFAULT 0.00
        -> , total_units_sold INT UNSIGNED NOT NULL DEFAULT 0
    );
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> INSERT INTO SalesSummary
        -> (product_name, total_sales, avg_unit_price, total_units_sold)
        -> VALUES
        -> ('cucumber', 100.25, 90, 2);
    
    mysql> SELECT * FROM SalesSummary;
    +--------------+-------------+----------------+------------------+
    | product_name | total_sales | avg_unit_price | total_units_sold |
    +--------------+-------------+----------------+------------------+
    | cucumber     |      100.25 |          90.00 |                2 |
    +--------------+-------------+----------------+------------------+
    1 row in set (0.00 sec)
    
    mysql> DROP TABLE SalesSummary;  
    mysql>  SELECT * FROM SalesSummary;  
    ERROR 1146: Table 'RUNOOB.SalesSummary' doesn't exist

    3、mybatis中临时表操作

       
            CREATE TEMPORARY TABLE IF NOT EXISTS temp 
            SELECT * FROM settlement_temp
             WHERE settle_date=#{settleDate} AND LENGTH(operator) IN(16,32) AND  pay_status IN ('01','06') 
             ORDER BY settle_date,merchant_no
        
      
          
            DROP TEMPORARY TABLE IF EXISTS settlement_temp;
        

    内部临时表的常见用法

      如果用户在书写SQL语句的时候能够尽量少的使用内部临时表进行查询优化,将有效的提高查询执行的效率。

    首先我们定义一个表t1,

    CREATE TABLE t1( a int, b int); 
    INSERT INTO t1 VALUES(1,2),(3,4);

    下面所有的操作都是基于表t1进行举例的。

    • 在SQL语句中使用SQL_BUFFER_RESULT hint

    SQL_BUFFER_RESULT主要用来让MySQL尽早的释放表上的锁。因为如果数据量很大的话,需要较长时间将数据发送到客户端,通过将数据缓冲到临时表中可以有效的减少读锁对表的占用时间。SQL_BUFFER_RESULT见《mysql查询优化之三:查询优化器提示(hint)》

    例如:

    mysql> explain format=json select SQL_BUFFER_RESULT * from t1;
        EXPLAIN
        {
          "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "2.00"
            },
            "buffer_result": {
              "using_temporary_table": true,
              "table": {
                "table_name": "t1",
                "access_type": "ALL",
            ...
    • 如果SQL语句中包含了DERIVED_TABLE。

    在5.7中,由于采用了新的优化方式,我们需要使用 set optimizer_switch=’derived_merge=off’来禁止derived table合并到外层的Query中。

    例如:

    mysql> explain format=json select * from (select * from t1) as tt;
        EXPLAIN
        {
          "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "2.40"
            },
            "table": {
              "table_name": "tt",
              "access_type": "ALL",
              ...
              "materialized_from_subquery": {
                "using_temporary_table": true,
            ...
    • 如果我们查询系统表的话,系统表的数据将被存储到内部临时表中。

    我们当前不能使用EXPLAIN来查看是否读取系统表数据需要利用到内部临时表,但是可以通过SHOW STATUS来查看是否利用到了内部临时表。

    例如:

    mysql> select * from information_schema.character_sets;
    mysql> show status like 'CREATE%';
    • 如果DISTINCT语句没有被优化掉,即DISTINCT语句被优化转换为GROUP BY操作或者利用UNIQUE INDEX消除DISTINCT, 内部临时表将会被使用。

    mysql> explain format=json select distinct a from t1;
        EXPLAIN
        {
        {
          "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "1.60"
            },
            "duplicates_removal": {
              "using_temporary_table": true,
            ...
    • 如果查询带有ORDER BY语句,并且不能被优化掉。下面几种情况会利用到内部临时表缓存中间数据,然后对中间数据进行排序。

    1)如果连接表使用BNL(Batched Nestloop)/BKA(Batched Key Access)
    例如:

    1))BNL默认是打开的

    mysql> explain format=json select * from t1, t1 as t2 order by t1.a;
    EXPLAIN
    {
      "query_block": {
      "select_id": 1,
      "cost_info": {
        "query_cost": "22.00"
      },
      "ordering_operation": {
        "using_temporary_table": true,
      ...

    2))关掉BNL后,ORDER BY将直接使用filesort。

    mysql> set optimizer_switch='block_nested_loop=off';
    Query OK, 0 rows affected (0.00 sec)
    mysql> explain format=json select * from t1, t1 as t2 order by t1.a;
    EXPLAIN
    {
       "query_block": {
        "select_id": 1,
        "cost_info": {
          "query_cost": "25.00"
        },
        "ordering_operation": {
          "using_filesort": true,
        ...

    2)ORDER BY的列不属于执行计划中第一个连接表的列。

    例如:

    mysql> explain format=json select * from t as t1, t as t2 order by t2.a;
    EXPLAIN
    {
       "query_block": {
        "select_id": 1,
        "cost_info": {
          "query_cost": "25.00"
        },
        "ordering_operation": {
          "using_temporary_table": true,
        ...

    3)如果ORDER BY的表达式是个复杂表达式。

    那么什么样的ORDER BY表达式,MySQL认为是复杂表达式呢?

    1))如果排序表达式是SP或者UDF。

    例如:

    drop function if exists func1;
    delimiter |
    create function func1(x int)
    returns int deterministic
    begin
    declare z1, z2 int;
    set z1 = x;
    set z2 = z1+2;
    return z2;
    end|
    delimiter ;
    explain format=json select * from t1 order by func1(a);
    {
        "query_block": {
        "select_id": 1,
        "cost_info": {
          "query_cost": "2.20"
        },
        "ordering_operation": {
          "using_temporary_table": true,
        ...

    2))ORDER BY的列包含聚集函数

    为了简化执行计划,我们利用INDEX来优化GROUP BY语句。

    例如:

    create index idx1 on t1(a);
      explain format=json SELECt a FROM t1 group by a order by sum(a);
      | {
           "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "1.20"
            },
            "ordering_operation": {
              "using_temporary_table": true,
              "using_filesort": true,
              "grouping_operation": {
                "using_filesort": false,
            ...
      drop index idx1 on t1;

    3))ORDER BY的列中包含有SCALAR SUBQUERY,当然该SCALAR SUBQUERY没有被优化掉。

    例如:

    explain format=json select (select rand() from t1 limit 1) as a from t1 order by a;        
    | {
          "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "1.20"
            },
            "ordering_operation": {
              "using_temporary_table": true,
              "using_filesort": true,
                ...

    4) 如果查询既带有ORDER BY同时也有GROUP BY语句,但是两个语句使用的列不相同。

    注意: 如果是5.7,我们需要将sql_mode设置为非only_full_group_by模式,否则会报错。

    同样为了简化执行计划,我们利用INDEX来优化GROUP BY语句。

    例如:

    set sql_mode='';
    create index idx1 on t1(b);
    explain format=json select t1.a from t1 group by t1.b order by 1;
    | {
         "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "1.40"
            },
        "ordering_operation": {
              "using_temporary_table": true,
              "using_filesort": true,
              "grouping_operation": {
                "using_filesort": false,
        ...
    drop index idx1 on t1;
    • 如果查询带有GROUP BY语句,并且不能被优化掉。下面几种情况会利用到内部临时表缓存中间数据,然后对中间数据进行GROUP BY。

    1)如果连接表使用BNL(Batched Nestloop)/BKA(Batched Key Access)。

    例如:

    explain format=json select t2.a from t1, t1 as t2 group by t1.a;
        | {
            "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "8.20"
            },
            "grouping_operation": {
              "using_temporary_table": true,
              "using_filesort": true,
              "cost_info": {
                "sort_cost": "4.00"
            ...

    2) 如果GROUP BY的列不属于执行计划中的第一个连接表。

    例如:

    explain format=json select t2.a from t1, t1 as t2 group by t2.a;
        | {
            "query_block": {
            "select_id": 1,
            "cost_info": {
              "query_cost": "8.20"
            },
            "grouping_operation": {
              "using_temporary_table": true,
              "using_filesort": true,
              "nested_loop": [
            ...

    3) 如果GROUP BY语句使用的列与ORDER BY语句使用的列不同。

    例如:

    	set sql_mode='';
    	explain format=json select t1.a from t1 group by t1.b order by t1.a;
    	| {
    	   "query_block": {
    		"select_id": 1,
    		"cost_info": {
    		  "query_cost": "1.40"
    		},
    		"ordering_operation": {
    		  "using_filesort": true,
    		  "grouping_operation": {
    			"using_temporary_table": true,
    			"using_filesort": false,
    		...

    4) 如果GROUP BY带有ROLLUP并且是基于多表外连接。

    例如:

    	explain format=json select sum(t1.a) from t1 left join t1 as t2 on true group by t1.a with rollup;
    	| {
    		"query_block": {
    		"select_id": 1,
    		"cost_info": {
    		  "query_cost": "7.20"
    		},
    		"grouping_operation": {
    		  "using_temporary_table": true,
    		  "using_filesort": true,
    		  "cost_info": {
    			"sort_cost": "4.00"
    		  },
    		...

    5) 如果GROUP BY语句使用的列来自于SCALAR SUBQUERY,并且没有被优化掉。

    例如:

    explain format=json select (select avg(a) from t1) as a from t1 group by a;
    | {
    "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "3.40"
    },
    "grouping_operation": {
      "using_temporary_table": true,
      "using_filesort": true,
      "cost_info": {
    "sort_cost": "2.00"
      },
    ...

    IN表达式转换为semi-join进行优化

    1) 如果semi-join执行方式为Materialization

    例如:

    set optimizer_switch='firstmatch=off,duplicateweedout=off';
    explain format=json select * from t1 where a in (select b from t1);
    | {
    "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "5.60"
    },
    "nested_loop": [
      {
    "rows_examined_per_scan": 1,
      "materialized_from_subquery": {
    "using_temporary_table": true,
    "query_block": {
      "table": {
    "table_name": "t1",
    "access_type": "ALL",
    ...

    2) 如果semi-join执行方式为Duplicate Weedout

    例如:

    set optimizer_switch='firstmatch=off';
    explain format=json select * from t1 where a in (select b from t1);
    | {
    "query_block": {
    "select_id": 1,
    "cost_info": {
      "query_cost": "4.80"
    },
    "duplicates_removal": {
      "using_temporary_table": true,
      "nested_loop": [
    {
    ...
    • 如果查询语句带有UNION,MySQL将利用内部临时表帮助UNION操作消除重复。

    例如:

    explain format=json select * from t1 union select * from t1;
    | {
    "query_block": {
    "union_result": {
      "using_temporary_table": true,
      "table_name": "",
    ...
    • 如果查询语句使用多表更新。

    这里Explain不能看到内部临时表被利用,所以需要查看status。

    例如:

    update t1, t1 as t2 set t1.a=3;
    show status like 'CREATE%';
    • 如果聚集函数中包含如下函数,内部临时表也会被利用。

    1) count(distinct *)
    例如:
    explain format=json select count(distinct a) from t1;
    2) group_concat
    例如:
    explain format=json select group_concat(b) from t1;

    总之,上面列出了10种情况,MySQL将利用内部临时表进行中间结果缓存,如果数据量比较大的话,内部临时表将会把数据存储在磁盘上,这样显然会对性能有所影响。为了尽可能的减少性能损失,我们需要尽量避免上述情况的出现。

    MySQL在以下几种情况会创建临时表:

    1、UNION查询;
    2、用到TEMPTABLE算法或者是UNION查询中的视图;
    3、ORDER BY和GROUP BY的子句不一样时;
    4、表连接中,ORDER BY的列不是驱动表中的;
    5、DISTINCT查询并且加上ORDER BY时;
    6、SQL中用到SQL_SMALL_RESULT选项时;
    7、FROM中的子查询;
    8、子查询或者semi-join时创建的表;

    EXPLAIN 查看执行计划结果的 Extra 列中,如果包含 Using Temporary 就表示会用到临时表。

    当然了,如果临时表中需要存储的数据量超过了上限( tmp-table-size 或 max-heap-table-size 中取其大者),这时候就需要生成基于磁盘的临时表了。

    在以下几种情况下,会创建磁盘临时表:

    1、数据表中包含BLOB/TEXT列;
    2、在 GROUP BY 或者 DSTINCT 的列中有超过 512字符 的字符类型列(或者超过 512字节的 二进制类型列,在5.6.15之前只管是否超过512字节);
    3、在SELECT、UNION、UNION ALL查询中,存在最大长度超过512的列(对于字符串类型是512个字符,对于二进制类型则是512字节);
    4、执行SHOW COLUMNS/FIELDS、DESCRIBE等SQL命令,因为它们的执行结果用到了BLOB列类型。

    从5.7.5开始,新增一个系统选项 internal_tmp_disk_storage_engine 可定义磁盘临时表的引擎类型为 InnoDB,而在这以前,只能使用 MyISAM。而在5.6.3以后新增的系统选项 default_tmp_storage_engine 是控制 CREATE TEMPORARY TABLE 创建的临时表的引擎类型,在以前默认是MEMORY,不要把这二者混淆了。

    见下例:

    mysql> set default_tmp_storage_engine = "InnoDB";
    -rw-rw----   1 mysql mysql  8558 Jul  7 15:22 #sql4b0e_10_0.frm -- InnoDB引擎的临时表
    -rw-rw----   1 mysql mysql 98304 Jul  7 15:22 #sql4b0e_10_0.ibd
    -rw-rw----   1 mysql mysql  8558 Jul  7 15:25 #sql4b0e_10_2.frm
    mysql> set default_tmp_storage_engine = "MyISAM";
    -rw-rw----   1 mysql mysql     0 Jul  7 15:25 #sql4b0e_10_2.MYD -- MyISAM引擎的临时表
    -rw-rw----   1 mysql mysql  1024 Jul  7 15:25 #sql4b0e_10_2.MYI
    mysql> set default_tmp_storage_engine = "MEMORY";
    -rw-rw----   1 mysql mysql  8558 Jul  7 15:26 #sql4b0e_10_3.frm -- MEMORY引擎的临时表
    本站声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系bd@zhengruan.com
    作者最新文章
    编程开发 MySQL
    相关文章 更多
    navicat导入数据库步骤详解及常见问题处理教程
    navicat导入数据库步骤详解及常见问题处理教程

    详解Navicat导入数据库的标准步骤,涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误,提供具体的设置方法与修复建议,确保数据迁移准确无误。

    SQL主键约束和唯一约束有什么区别
    SQL主键约束和唯一约束有什么区别

    深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发,详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例,指导开发者如何根据字段稳定性与业务语义合理选择约束类型,避免设计误区。

    SQL约束有哪些类型及作用
    SQL约束有哪些类型及作用

    刚开始设计关系型数据库?了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主,结合用户订单场景,清晰展示如何防止脏数据并处理常见约束冲突。

    SQL游标常见错误排查:死锁与资源未释放问题
    SQL游标常见错误排查:死锁与资源未释放问题

    深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比,展示如何识别长事务持锁、分析锁等待链,并提供短事务提交、异常清理及批量处理的最佳实践,确保数据库连接与锁资源及时释放。

    SQL中怎么创建和删除约束
    SQL中怎么创建和删除约束

    后端开发者在维护数据库时,常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT,往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法,帮助你在生产环境安全完成结构变更。

    SQL分组统计查询:GROUP BY与HAVING子句用法示例
    SQL分组统计查询:GROUP BY与HAVING子句用法示例

    针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异,以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果,并排查因 JOIN 连接导致的统计数据异常,提升报表准确性。

    SQL Server与MySQL游标基本语法及完整代码示例
    SQL Server与MySQL游标基本语法及完整代码示例

    本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历,再到CLOSE关闭与DEALLOCATE/Handler清理,解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标,避免资源泄漏,适用于需要进行数据库存储过程开发或跨平台迁移的开发者。

    SQL多表连接区别:INNER JOIN与LEFT JOIN的使用场景
    SQL多表连接区别:INNER JOIN与LEFT JOIN的使用场景

    深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例,展示匹配行保留与NULL补位机制,重点讲解ON与WHERE子句中放置右表过滤条件的不同后果,提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。

    SQL CHECK约束的用法与取值范围限制
    SQL CHECK约束的用法与取值范围限制

    深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景,讲解如何定义单列范围与多列逻辑约束,分析 NULL 值对布尔条件的影响,并提供修改已有表结构时的安全操作建议,帮助开发者构建更健壮的数据完整性防线。

    SQL外键约束怎么用及级联操作说明
    SQL外键约束怎么用及级联操作说明

    后端开发中,如何正确使用 SQL 外键约束来维护订单与明细表的关系?本文通过 PostgreSQL 示例,深入讲解外键的创建语法、插入顺序要求,以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制,助你构建健壮的数据库结构。

    查看更多
    精品专题 更多
    装机必备
    装机必备

    正软商城装机必备专区,精选办公、浏览器、安全防护、影音播放、压缩解压、设计创作和系统工具等电脑常用正版软件,帮助用户快速完成新电脑软件配置。

    Windows
    Windows

    正软商城Windows软件专区,汇集适用于Windows电脑的办公、设计、安全防护、影音播放、开发工具和系统优化软件,提供软件介绍、系统要求、正版授权及购买下载服务。

    PDF教程
    PDF教程

    正软商城PDF教程频道提供PDF编辑、转换、合并、拆分、压缩及格式处理方法,同时介绍常用PDF软件和工具的使用技巧。

    Mac软件 更多
    讯飞智作 网页版
    讯飞智作 网页版
    Windows/ macOS/ Linux

    讯飞智作是一款基于语音合成技术、虚拟人驱动技术与数字人形象声音构建能力的 AI 数字人音视频创作平台。

    火山引擎 网页版
    火山引擎 网页版
    Windows/ macOS/ Linux

    火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力,依托字节自研豆包多模态大模型,凭借火山方舟一站式平台,提供模型精调、推理部署、智能应用搭建等全链路服务,结合高性能AI算力,助力各行业快速落地大模型数字化与智能化应用。

    Aperty macOS版
    Aperty macOS版
    macOS

    Aperty 是 Skylum 推出的 AI 人像修图软件,支持自然肤质修饰、瑕疵处理、面部与身体调整、预设及批量同步。

    WINDOWS 更多
    讯飞智作 网页版
    讯飞智作 网页版
    Windows/ macOS/ Linux

    讯飞智作是一款基于语音合成技术、虚拟人驱动技术与数字人形象声音构建能力的 AI 数字人音视频创作平台。

    火山引擎 网页版
    火山引擎 网页版
    Windows/ macOS/ Linux

    火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力,依托字节自研豆包多模态大模型,凭借火山方舟一站式平台,提供模型精调、推理部署、智能应用搭建等全链路服务,结合高性能AI算力,助力各行业快速落地大模型数字化与智能化应用。

    PixTV 网页版
    PixTV 网页版
    Windows

    PixTV 是一款在浏览器中使用的 AI 视觉内容创作平台,提供图片、视频、音频、文字生成、AI 分镜、局部重绘、提示词反推和无限画布等工具,适合短剧、漫剧、广告及社交媒体内容制作。