[
https://issues.apache.org/jira/browse/FLINK-38555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18034104#comment-18034104
]
Ruan Hang commented on FLINK-38555:
-----------------------------------
|*MySQL Type*|*Java type from getObject with select sql*|*Java type from
parsing binlog with debezium*|
|SERIAL|java.math.BigInteger|java.math.BigDecimal|
|TINYINT|java.lang.Integer|java.lang.Short|
|TINYINT UNSIGNED|java.lang.Integer|java.lang.Short|
|TINYINT UNSIGNED ZEROFILL|java.lang.Integer|java.lang.Short|
|SMALLINT|java.lang.Integer|java.lang.Short|
|SMALLINT UNSIGNED|java.lang.Integer|java.lang.Integer|
|SMALLINT UNSIGNED ZEROFILL|java.lang.Integer|java.lang.Integer|
|MEDIUMINT|java.lang.Integer|java.lang.Integer|
|MEDIUMINT UNSIGNED|java.lang.Integer|java.lang.Integer|
|MEDIUMINT UNSIGNED ZEROFILL|java.lang.Integer|java.lang.Integer|
|INTEGER|java.lang.Integer|java.lang.Integer|
|INTEGER UNSIGNED|java.lang.Long|java.lang.Long|
|INTEGER UNSIGNED ZEROFILL|java.lang.Long|java.lang.Long|
|INT(11)|java.lang.Integer|java.lang.Integer|
|BIGINT|java.lang.Long|java.lang.Long|
|BIGINT UNSIGNED|java.math.BigInteger|java.math.BigDecimal|
|BIGINT UNSIGNED ZEROFILL|java.math.BigInteger|java.math.BigDecimal|
|VARCHAR(255)|java.lang.String|java.lang.String|
|CHAR(3)|java.lang.String|java.lang.String|
|REAL|java.lang.Double|java.lang.Double|
|FLOAT|java.lang.Float|java.lang.Float|
|FLOAT UNSIGNED|java.lang.Float|java.lang.Float|
|FLOAT UNSIGNED ZEROFILL|java.lang.Float|java.lang.Float|
|DOUBLE|java.lang.Double|java.lang.Double|
|DOUBLE UNSIGNED|java.lang.Double|java.lang.Double|
|DOUBLE UNSIGNED ZEROFILL|java.lang.Double|java.lang.Double|
|DECIMAL(8, 4)|java.math.BigDecimal|java.math.BigDecimal|
|DECIMAL(8, 4) UNSIGNED|java.math.BigDecimal|java.math.BigDecimal|
|DECIMAL(8, 4) UNSIGNED ZEROFILL|java.math.BigDecimal|java.math.BigDecimal|
|NUMERIC(6, 0)|java.math.BigDecimal|java.math.BigDecimal|
|DECIMAL(65, 1)|java.math.BigDecimal|java.math.BigDecimal|
|BIT|java.lang.Boolean|java.lang.Boolean|
|TINYINT(1)|java.lang.Integer|java.lang.Short|
|BOOLEAN|java.lang.Integer|java.lang.Short|
|DATE|java.time.LocalDate|java.lang.Integer|
|TIME(0)|java.time.Duration|java.lang.Long|
|DATETIME(3)|java.sql.Timestamp|java.lang.Long|
|DATETIME(6)|java.sql.Timestamp|java.lang.Long|
|TIMESTAMP|java.sql.Timestamp|java.lang.String|
|BINARY(16)|[B|java.nio.HeapByteBuffer|
|BIT(64)|[B|[B|
|TEXT|java.lang.String|java.lang.String|
|TINYBLOB|[B|java.nio.HeapByteBuffer|
|BLOB|[B|java.nio.HeapByteBuffer|
|MEDIUMBLOB|[B|java.nio.HeapByteBuffer|
|LONGBLOB|[B|java.nio.HeapByteBuffer|
|YEAR|java.sql.Date|java.lang.Integer|
|enum('red', 'white')|java.lang.String|java.lang.String|
|SET('a', 'b')|java.lang.String|java.lang.String|
|JSON|java.lang.String|java.lang.String|
|POINT|[B|org.apache.kafka.connect.data.Struct|
|GEOMETRY|[B|org.apache.kafka.connect.data.Struct|
|LINESTRING|[B|org.apache.kafka.connect.data.Struct|
|POLYGON|[B|org.apache.kafka.connect.data.Struct|
|MULTIPOINT|[B|org.apache.kafka.connect.data.Struct|
|MULTILINESTRING|[B|org.apache.kafka.connect.data.Struct|
|MULTIPOLYGON|[B|org.apache.kafka.connect.data.Struct|
|GEOMCOLLECTION|[B|org.apache.kafka.connect.data.Struct
|
Hi, [~heigebupahei] . I make a table for you. The split start and end are
gotten from getObject() with the select sql. The chunk key is from parsing
binlog with debezium.
If we want to support all types, maybe we need to compare the data with
different java type in this table.
> Optimize performance of `RecordUtils.compareObjects()` method by avoiding
> unnecessary `toString()` calls for temporal types (LocalDateTime, LocalDate,
> Instant, etc.).
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: FLINK-38555
> URL: https://issues.apache.org/jira/browse/FLINK-38555
> Project: Flink
> Issue Type: Bug
> Components: Flink CDC
> Affects Versions: cdc-3.5.0
> Reporter: yuanfenghu
> Assignee: yuanfenghu
> Priority: Critical
> Fix For: cdc-3.6.0
>
> Attachments: image-2025-10-24-10-15-18-027.png,
> image-2025-10-24-10-15-37-328.png
>
>
> h2. Background
> While analyzing flame graphs of a Flink CDC MySQL source job, I identified
> that `RecordUtils.splitKeyRangeContains()` was a performance bottleneck.
> Further investigation revealed that `compareObjects()` was using `toString()`
> to compare temporal objects, which is significantly slower than direct
> comparison.
>
> h3. Root Cause
> h3.
> In the current implementation:
> {code:java}
> private static int compareObjects(Object o1, Object o2) {
> if (o1 instanceof Comparable && o1.getClass().equals(o2.getClass())) {
> return ((Comparable) o1).compareTo(o2);
> } else if (isNumericObject(o1) && isNumericObject(o2)) {
> return toBigDecimal(o1).compareTo(toBigDecimal(o2));
> } else {
> return o1.toString().compareTo(o2.toString());
> }
> }{code}
> When comparing `LocalDateTime` objects, the first condition fails if the
> objects are cast to `Object`, falling through to the `toString()` comparison
> path.
> h3. Impact
> This method is called extensively during the snapshot phase when evaluating
> whether binlog records fall within completed split ranges. For tables with:
> - Temporal types (DATETIME, TIMESTAMP, DATE, TIME) as chunk keys
> - High binlog throughput during snapshot phase
> - Many splits (large tables with small chunk size)
> The performance impact can be significant (80% CPU in some cases).
> !image-2025-10-24-10-15-37-328.png!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
