MySQL BIGINT对于插入不一致？

Question

在ubuntu上。。运行MySQLV5.6。 创建了一个python程序来执行我的所有操作

我的应用程序动态创建表。有很多。有几个非常相似。。例如，这里有两个：

create table tst.intgn_party_test_load (
  party_id bigint unsigned NOT NULL,
  party_supertype varchar(15) NOT NULL,
  carrier_party_id bigint unsigned NOT NULL,
  full_name varchar(500),
  lda_actv_ind integer,
  lda_file_id integer,
  lda_created_by varchar(100),
  lda_created_on datetime,
  lda_updated_by varchar(100),
  lda_updated_on datetime, 
  PRIMARY KEY(party_id,party_supertype,carrier_party_id)
) 

及

create table tst.intgn_party_relationship (
  parent_party_id bigint unsigned NOT NULL,
  child_party_id bigint unsigned NOT NULL,
  relationship_type varchar(10),
  lda_actv_ind integer,
  lda_file_id integer,
  lda_created_by varchar(100),
  lda_created_on datetime,
  lda_updated_by varchar(100),
  lda_updated_on datetime, 
  PRIMARY KEY(parent_party_id,child_party_id,relationship_type)
) 

我的程序还动态地填充表。我使用转换为BIGINT的源数据构造party id字段。 例如，它为第一个表构造的插入为：

INSERT INTO intgn_party_test_load (
  party_supertype, 
  carrier_party_id, 
  party_id, 
  full_name, 
  lda_actv_ind, 
  lda_file_id) 
SELECT  
  'Agency' as s0,
  0 as s1,
  CONV(SUBSTRING(CAST(SHA(CONCAT(full_name,ga)) AS CHAR), 1, 16), 16, 10) as s2,
  CONCAT(full_name,'-',ga) as s3, 
  lda_actv_ind, 
  lda_file_id 
FROM tst.raw_listing_20210118175114 
ON DUPLICATE KEY 
UPDATE  
  full_name = VALUES(full_name), 
  lda_actv_ind = VALUES(lda_actv_ind), 
  lda_file_id = VALUES(lda_file_id) ;

对于第二个表，构建的insert看起来非常相似，并且基于完全相同的源数据：

INSERT INTO tst.intgn_party_relationship (
  parent_party_id,
  relationship_type,
  child_party_id, 
  lda_actv_ind, 
  lda_file_id) 
SELECT (Select party_id 
        from intgn_party 
        where full_name = 'xxx') as s0,
       'Location' as s1,
       CONV(SUBSTRING(CAST(SHA(CONCAT(full_name,ga)) AS CHAR), 1, 16), 16, 10) as s2, 
       lda_actv_ind, 
       lda_file_id 
FROM tst.raw_listing_20210118175114 
ON DUPLICATE KEY 
UPDATE  
  lda_actv_ind = VALUES(lda_actv_ind), 
  lda_file_id = VALUES(lda_file_id) 

现在。。。第一个表（intgn\u party\u test\u load）是问题所在。我可以删除它，手动重新创建它，甚至。。无论我做什么，通过python插入的数据都会将BIGINT party_id截断为16位。 使用完全相同的公式填充party_id的其他每个表都会创建长度在18到20位之间的BIGINT数字。我可以在表中看到加载的所有相同源记录，在第一个表中看到截断的值（intgn_party_test_load）。例如，第一个表有一个参与方id为7129232523783260的记录。第二个表（和许多其他表）具有加载了[child]party id=7129232523783260081的相同记录

完全相同的公式，以与python完全相同的方式执行。。但是这张桌子的大整数变短了

有趣的是，我尝试手动将insert运行到这个表中（不使用python程序），它将插入完整的BIGINT值。 所以我很困惑为什么python程序“选择”这个表不能正常工作，而它在所有其他表上都能正常工作

是否存在值被截断的奇怪情况？ 顺便说一句，我的python程序利用sqlalchemy来运行创建/插入。因为它是手动工作的，所以我不得不假设它与sqlalchemy有关。。但是除了这张桌子，我不知道为什么它对所有人都有效

[编辑] 要添加，通过sqlalchemy执行的sql命令使用db_connection.execute(sql)

[编辑-添加更多代码详细信息]

from sqlalchemy import create_engine, exc

engine = create_engine(
            connection_string,
            pool_size=6, max_overflow=10, encoding='latin1', isolation_level='AUTOCOMMIT'
        )
        connection = engine.connect()

sql = "INSERT INTO intgn_party_test_load (
  party_supertype, 
  carrier_party_id, 
  party_id, 
  full_name, 
  lda_actv_ind, 
  lda_file_id) 
SELECT  
  'Agency' as s0,
  0 as s1,
  CONV(SUBSTRING(CAST(SHA(CONCAT(full_name,ga)) AS CHAR), 1, 16), 16, 10) as s2,
  CONCAT(full_name,'-',ga) as s3, 
  lda_actv_ind, 
  lda_file_id 
FROM tst.raw_listing_20210118175114 
ON DUPLICATE KEY 
UPDATE  
  full_name = VALUES(full_name), 
  lda_actv_ind = VALUES(lda_actv_ind), 
  lda_file_id = VALUES(lda_file_id) ;"

        result = db_connection.execute(sql)

这是我能做的最好的缩减（代码要复杂得多，因为它会动态地创建一个包含其他内容的语句）。。但是从我的日志中，我看到了它正在执行的确切语句（如上所述），并且在后面的BIGINT列中看到了结果。除了这张桌子，所有的桌子都有。只有在通过应用程序时。 因此，即使通过应用程序，其他表也不会发生这种情况

非常令人困惑。。希望有人知道mySQL 5.6中关于BIGINTs的一个bug，因为它可能与目标表的键结构或记录的总长度有关。。或者其他疯狂的原因。有趣的是，如果我在BIGINT列上做一个有>；18位长度，返回为16位-猜测distinct函数不支持BIGINT。。 我有点希望这暗示了一个问题，但我不明白为什么其他的表可以很好地工作

[编辑-添加一些我看到sqlalchemy运行的东西，显然是围绕我的查询的实际运行..只是在疯狂的情况下，它们会影响任何东西-对于一个表？？]

SET AUTOCOMMIT = 0
SET AUTOCOMMIT = 1
SET NAMES utf8mb4
SHOW VARIABLES LIKE 'sql_mode'
SHOW VARIABLES LIKE 'lower_case_table_names'
SELECT VERSION()
SELECT DATABASE()
SELECT @@tx_isolation
show collation where `Charset` = 'utf8mb4' and `Collation` = 'utf8mb4_bin'
SELECT CAST('test plain returns' AS CHAR(60)) AS anon_1
SELECT CAST('test unicode returns' AS CHAR(60)) AS anon_1
SELECT CAST('test collated returns' AS CHAR CHARACTER SET utf8mb4) COLLATE utf8mb4_bin AS anon_1
ROLLBACK
SET NAMES utf8mb4

很难说是什么命令之类的。。有一吨在同一微秒运行

Answer 1

在绞尽脑汁数天之后。。从各个角度来看，我都不明白为什么很多表中有一个表存在截断SHA'd值的问题。 最后，我重新设计了如何保存我的ID，我不再费心转换成BIGINT。当我把它留作字符时，一切都很好

CAST(SHA(CONCAT(full_name,ga)) AS CHAR)

因此，将所有我的Id列更改为varchar（40），并使用上述样式。现在一切都好了。join将使用varchar而不是bigint，我同意这一点