MySQL如何将十六进制类型的列与表示十六进制值的字符串进行比较

我有一个数据库视图，它有一个从bigint转换为hex的列。我还有以下存储过程：

CREATE PROCEDURE giveMeRows(pId varchar(64))
   BEGIN
     select * viewRowGiver Where Column1 = pId
   END

对于上面存储过程中的视图，“Column1”是十六进制值。“pId”是从网页调用传入的字符串值。更清楚地说，“pId”是Column1的文本表示形式。但是，在上面的存储过程中使用时，返回的结果是零行（它应该至少返回1）

我猜将十六进制与字符串进行比较并不是一种好方法

这样比较是行不通的：

第1列=十六进制（pId）

当基础表中有数百行时，这样的比较需要相当长的时间（最多20秒）：

CONV（第2、16、10列）=CONV（pId、16、10）

有没有办法解决这个问题，让它在不花费太多时间的情况下工作

编辑以使用示例数据显示整个过程：

**BASE TABLE** 
CREATE TABLE `BaseTable` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `DevID` bigint(20) unsigned DEFAULT NULL,
  `Nickname` varchar(256) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uniqueOne` (`DevID`,`ArrayIndex`)
) ENGINE=InnoDB AUTO_INCREMENT=196742 DEFAULT CHARSET=latin1;

Produces this kind of data
1355742314703884    Item 1
1090982514412804    Item 2
1100905476801632    Item 3
819808395279156     Item 4
947267619541158     Item 5
978328868008274     Item 6
45394831601695870   Item 7

**VIEW (this view is also called to get all rows to be displayed on a website)**
CREATE VIEW viewFromBaseTable
  SELECT HEX(DevID) as Column1, Nickname FROM BaseTable

Produces this kind of data
4D10A5B132C0C   Item 1
3E03E293A4D04   Item 2
3E94487E04460   Item 3
2E99C842F3B34   Item 4
35D88EDF850A6   Item 5
379C8F0A6B152    Item 6
A1465BDC41FC7E   Item 7

**STORED PROCEDURE(the where clause here works, albeit slower than it should)**
CREATE PROCEDURE procGetRowsById(pId varchar(64))
  BEGIN
    SELECT * FROM viewFromBaseTable WHERE CONV(Column1, 16, 10) = CONV(pId, 16, 1)
  END

调用存储过程“procGetRowsById”的网站代码将pId作为viewFromBaseTable中生成的“十六进制”值的“字符串”表示形式发送。希望这能澄清这个过程。

编辑：

在BaseTable上执行，并直接使用bigint进行比较

delimiter //
CREATE PROCEDURE procGetRowsById(pId varchar(64))
  BEGIN
    SELECT HEX(DevID) as Column1, Nickname FROM BaseTable WHERE DevID = CONV(pId, 16, 10);
  END
//
delimiter ;

mysql> call procGetRowsById('4D10A5B132C0C');
+---------------+------------+
| Column1       | Nickname   |
+---------------+------------+
| 4D10A5B132C0C | DaNickName |
+---------------+------------+
1 row in set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

---

这应该行得通。您确定要以数字而不是字符串的形式传入参数吗？十六进制（数字）不同于十六进制（字符串）。相反，我将参数作为字符串而不是数字传递。参数值类似于“1CAE09874775A”，请显示一些示例数据。您想匹配什么？按照上面提到的方法将十六进制（第1列）与十进制（conv（pId，16，10））进行比较。不管怎样，我只是为了好玩和咯咯笑而尝试了它，结果它返回了“0”行。对不起，我以为Column1是bigint。Column1的MySQL数据类型到底是什么？你能给我一个Column1值的例子吗？不幸的是，我一直在使用MySQL的一个版本，当处理一个超过一定数量的bigint时，它会崩溃。为了能够处理将这些值从web传输到数据库的问题，在视图中将列设置为十六进制是一种折衷方法。请再次编辑答案。让过程直接处理BaseTable怎么样？我试图避免这种情况，但在这种情况下，由于过程花费的时间太长，我将不得不这样做。使用视图的原因是这些“基本”表是遗留的，没有标准化，并且当前正在用于生产。我会接受这个答案，因为我们已经缩减了我们的选择，找到了一个可以接受的解决方案。