开启新数据类型的主要影响有

关键字INT语义的变化。 打开新类型后SQL中的INT关键字是指32位整型，例如cast(a as INT)是将a类型转换成32位整型。 未打开新类型时SQL中的INT关键字会被转换成BIGINT，是64位整型。例如，SQL中cast(a as INT)相当于cast(a as BIGINT)，create table t(a INT)相当于create table a (BIGINT)。 为与MaxCompute原有模式兼容，在未打开新数据类型时仍保留此转换，但会抛出一个告警提示INT被当作BIGINT处理了。如果您的脚本有此种情况，建议将INT全部改写为BIGINT，避免混淆。

关键字BIGINT解析的变化。 单独一个整型常量（例如123），在原数据类型下是BIGINT类型，在新数据类型下是INT类型。此变化可能会导致兼容性问题。

整型常量的语义变化 。 例如SELECT 1 + a; 中的整型常量1： 未打开新类型时，会被当做BIGINT来处理（如果这个常量太长了，超过了BIGINT的值域，如1000000000000000000000000，则会被当做DOUBLE来处理）。 打开新类型后， 整型常量会优先被解释为INT类型的32位整型的1（如果这个常量的值超过了INT的值域而又没有超过BIGINT的值域，则会解释为 BIGINT类型。如果超过了BIGINT的值域，则会解释为DOUBLE类型）。 此语义变化可能会导致兼容性问题。例如，类型是INT导致后续一些操作调用函数类型不一致，包括落盘（即写入磁盘）后生成的新数据类型表会导致周边工具以及后续作业的行为改变。

隐式类型转换规则变化。 打开新数据类型时某些隐式类型转换会被禁用，包括STRING->BIGINT、STRING->DATETIME、DOUBLE->BIGINT、DECIMAL->DOUBLE、DECIMAL->BIGINT都是有精度损失或者报错的风险。这种情况可以通过cast函数做强制转换的方式来解决。 隐式类型转换对函数调用和INSERT语句影响较大。例如，未开启新类型时能执行通过的SQL，在开启新后执行会报错。 对内置函数、UDF的影响。 在未打开新数据类型时，部分以新数据类型作为参数和返回值的操作及内置函数会被直接忽略，打开新数据类型后才可以正常使用。主要影响如下： 一些内置操作必须打开新数据类型才能使用，例如返回INT类型的函数（接受INT作为参数的内置函数，基本都有BIGINT的重载），例如YEAR、QUARTER、MONTH、DAY、HOUR、MINUTE、SECOND、MILLISECOND、NANOSECOND、DAYOFMONTH、WEEKOFYEAR。这些函数可以用DATEPART来实现。 UDF的Resolve不一致。例如UDF包含BIGINT和INT两个重载，原数据类型下由于无法识别INT，一定会执行BIGINT的重载，而新数据类型下可能会被解析为INT的重载。 IN表达式的类型解析不同。 IN表达式，例如 a in (1, 2, 3) ：

未打开新类型时，要求IN后面的括号里的所有值，其类型必须一致。 打开新类型后，IN后面的括号里的所有值支持隐式类型转换一致。 分区列支持的类型不同。 未打开新类型时分区列的类型仅支持STRING。 未打开新类型时，INSERT操作中的分区字段，要当做STRING类型来处理。

打开新类型后，分区列的类型支持STRING、VARCHAR、CHAR、TINYINT、SMALLINT、INT、BIGINT。 例如，insert overwrite table t partition (pt = 045) select ...;，此处045没有引号，应该当成整型来解析，045实际上是45。但是未打开新类型时，当作STRING类型处理，即为045，打开新类型后，当作整型来处理，即为45。

集合操作中的LIMIT语句行为变更。 例如SELECT * FROM t1 UNION ALL SELECT * FROM t2 limit 10;语句： 未打开新类型时，实际是SELECT * FROM t1 UNION ALL SELECT * FROM ( SELECT * FROM t2 limit 10) t2;。 打开新类型后，是SELECT * FROM (SELECT * FROM t1 UNION ALL SELECT * FROM t2 ) t limit 10;。 具有相同行为的操作，除了交集、并集和补集、INTERSECT和EXCEPT等集合操作，还有LIMIT、ORDER BY、DISTRIBUTE BY、SORT BY、CLUSTER BY操作。