我有一个名为customers的表，其中pk是一个int。
将这个字段加入BIGINT的表是否有任何性能问题或问题，当我说加入时我的意思是内连接。
我知道这是不好的做法，但是不是我的项目。
由于
答案 0 :(得分：3)
是。根据{{3}}规则，您将获得隐式扩展转化。
int列中的任何索引都很可能会被忽略。鉴于这是PK，它可能非常表现不佳。如果你明确地进行CAST也是如此。
不幸的是，选项可以是修复设计，也可以添加一个计算的索引列，因此它是bigint JOIN bigint。如果您无法更改表格，请运行它并查看：如果您有几百或几千行，那么您可能没问题。如果它是数百万，那么你就是技术上称为bollixed的东西。
答案 1 :(得分：2)
我的建议是进行显式转换并使用计算列和索引来解决任何性能问题。计算列只是bigint列值转换为int。
请参阅以下链接 -
答案 2 :(得分：1)
听起来你无能为力（除了将数据复制到具有匹配数据类型的表格），所以我不知道该说些什么。它会对性能产生影响，但可能不如从varchar或double转换那么糟糕。
如果你的主键是int并且这是一个外键bigint，那么bigint永远不应该保持int范围之外的任何东西，所以选择将bigint转换为int（而不是从int转发） to bigint）永远不会产生问题。
此外，根据您的查询及其执行计划，性能命中可能会最小化 - 取决于连接方向，内部或外部联接，基数/统计信息，哪些索引可用等等。
答案 3 :(得分：0)
我不知道因为我从未构建过这样的系统！我所能建议的只是克隆表，分析系统，更改数据类型以匹配然后重新分析。
然而我的直觉是转换类型会有一些开销。所以也许你也可以通过分析一个已知系统（比如PK int to int）然后在join子句中插入一个显式的强制转换（比如说int int到int-cast-as-bigint）来模拟这个，看看会发生什么